Times are UTC Toggle Colours
00:05:22 *** Seberoth_ has joined #openttdcoop.devzone 00:05:38 <GT> Anyway, bedtime for me too, CU. 00:06:28 <Rubidium> good night :) 00:06:33 <GT> Gute Nacht en welterusten 00:06:35 <Rubidium> sweet dreams about profiling :) 00:06:56 <GT> Grrrr.... 00:07:55 *** GT has left #openttdcoop.devzone 00:09:38 *** Seberoth has quit IRC 01:09:46 *** thgergo has quit IRC 07:13:07 *** ODM has joined #openttdcoop.devzone 07:33:27 <andythenorth> morning 07:41:20 <andythenorth> @seen alberth 07:41:20 <Webster> andythenorth: alberth was last seen in #openttdcoop.devzone 13 hours, 39 minutes, and 42 seconds ago: <Alberth> wow, hg import is quite useful 07:52:51 *** thgergo has joined #openttdcoop.devzone 08:02:30 *** Alberth has joined #openttdcoop.devzone 08:02:54 <Alberth> good morning 08:03:49 <Alberth> so far I managed not to consider how to solve the > 255 entries problem of town names, unfortunately, I now must come up with a nice algorithm :p 08:04:00 <andythenorth> hi Alberth 08:04:50 <andythenorth> I've got the results of a test run for industry patch 08:04:53 <andythenorth> I'll post in forums 08:14:08 <Alberth> just noticed, was about to read it :) 08:19:28 <Alberth> Retailmarket <-- make it "Retail market" ? 08:20:08 <andythenorth> probably 08:20:22 <andythenorth> yes, that's a mistake 08:23:14 <andythenorth> Alberth: resp. industry creation.... 08:23:27 <andythenorth> the key issue I'm puzzled by is this 08:23:52 <andythenorth> at map generation, game tries to create n industries. So in 1830 with many types not available, it fills the map with farms 08:24:08 * Alberth nods 08:24:13 <andythenorth> then later, limit n is reached, so it can only force one type of each new industry 08:24:43 <andythenorth> does there need to be some way to adjust the limit according to time? 08:25:28 <Alberth> yes, you can force one industry on the map, and that forced build is taken from the 'free' space for the other industries 08:25:49 <Alberth> in current trunk, the number of industries is fixed 08:26:21 <Alberth> in my patch, I increase the number of industries slowly: M(40, 80), // high 08:26:44 <Alberth> means go from 40 in 1950 to 80 in 2050, for each 256x256 map 08:27:03 <Alberth> ie for 512x256, you must double those numbers 08:27:23 <Alberth> for 2Kx2K, multiply by 8*8=64 08:27:47 <andythenorth> is 1950 a fixed date? 08:28:08 <Alberth> it is a compile-time constant :) 08:28:46 <Alberth> see GetNumberOfIndustries() 08:29:40 <Alberth> I get the feeling that the large number of industry types gets in the way for a map of 512x256 08:29:48 <andythenorth> probably 08:30:03 <andythenorth> I intended to run it on 'normal', but must have made a mistake :P 08:31:22 <andythenorth> I'll run another test with different settings 08:31:41 <Alberth> that would be more bad: M(27, 55), // normal 08:33:36 <andythenorth> does the total number of available industry types need to be a factor for the limit, rather than absolute dates? 08:33:39 <Alberth> in a sense, you'd want to keep some fraction of industries 'free' for new industry-types that appear leater 08:40:00 <andythenorth> Alberth: how would you know what types will appear later? 08:40:37 <Alberth> did you enable closing of industries in the test? If not, then you have very little room for renewal, as the patch will not create more unforced industries than allowed 08:41:17 <Alberth> a simple way would be to pretend all industries are available, give them target counts, but never build them 08:41:35 <andythenorth> blunt but simple 08:41:37 <Alberth> but it would be a waste for industries that are available only late in the game 08:42:12 <andythenorth> game can't know when a newgrf intends to build an industry? 08:42:19 <andythenorth> (make it available) 08:42:49 <andythenorth> it probably shouldn't try to know that - it's too tightly coupled 08:43:00 <Alberth> I did not encounter that information 08:43:23 <andythenorth> I don't think it's appropriare to try and use it 08:43:50 <andythenorth> appropriate /s 08:44:03 <Alberth> then I'd also like to know when an industry wants to close probably, so I can make a plan 08:44:20 <andythenorth> that would reopen the whole closures issue 08:44:39 <andythenorth> which might be worth fixing....but extends the scope of your patch quite horribly ;) 08:44:53 <andythenorth> closure routine currently sucks 08:45:03 <Alberth> I think closing in itself is not the problem, the fact that not enough new ones are created is the problem 08:45:17 <andythenorth> the problem with closures is mass wave 08:45:47 <andythenorth> instead of basing it on dumb 5 year limit, an equivalent 'close' routine to your 'open' routine would get better results 08:46:01 <andythenorth> I tried doing it nfo, based on industry counts, but it's too fragile 08:46:15 <Alberth> there is a flaw somewhere in the creation probably, they are created at the same time, so they close at the same time, get rebuilt at the same time, close at the same time, etc etc 08:47:12 <andythenorth> I'm not sure of the cause. The five year protected period is one obvious factor. I tried moving that across to nfo, but randomised for more spread. Wasn't massively helpful 08:47:34 <andythenorth> The other factor is whether the 'random production change' is acting as it should be 08:48:07 <andythenorth> every time frosch looks at it he seems to find mistakes in this part of industry code :P 08:48:22 <Alberth> I agree that the game should be able to have more control over closure, the game has a much better idea of what exists 08:48:41 <andythenorth> unless grf-local storage is available, it's never going to work in nfo 08:49:16 <Alberth> moving closure control to nfo was a dumb move imho 08:49:22 <andythenorth> I could talk about complexity theory and phase transitions from independent agents...but I won't :) 08:49:32 <Alberth> phew :) 08:49:54 <andythenorth> some closure control in nfo is valid, but not at the level where we're trying to provide a sane economy to player 08:50:29 <andythenorth> with TownControl (and hence some form of grf-local storage) it might be more possible, but it will still be horribly ugly 08:51:14 <andythenorth> the ideal would be to (a) space closures in some sensible way (b) notify newgrf that an industry is marked for closure. 08:51:58 <andythenorth> if (b) set a cb flag to run every month, the newgrf could still affect closure in interesting ways (via allow/disallow closure) 08:52:37 <andythenorth> i.e. there could be a message to player, and a chance to save the industry (by providing service or whatever) 08:52:50 <Alberth> pay money to keep me open :p 08:53:00 <andythenorth> :D 08:53:23 <andythenorth> currently it's pretty much 'boom' this industry is gone :P 08:53:59 <Alberth> do you take closure of 'old' indsutries into account? 08:54:29 <andythenorth> do you mean default ttd industries, or 'outdated' industries?? 08:54:58 <Alberth> if you look at the industry output, you see that industries at the bottom of the list pretty much hold on to their amounts rather than giving them up to the 'newer' ones 08:55:16 <Alberth> (the list is sorted on 'most wanted' to 'least wanted' 08:55:21 <Alberth> ) 08:55:37 <andythenorth> hmm 08:55:41 <andythenorth> interesting question 08:56:00 <Alberth> so one way of getting movement would be to increase the chance of closing down the ones at the bottom 08:56:15 <andythenorth> I think it's too hard to know whether it's 'old but still vital' or 'old and superceded' 08:56:31 <Alberth> year? 08:56:31 <andythenorth> I've slightly abandoned the concept of closing industry types by time in FIRS 08:56:38 <andythenorth> it will be too annoying to players 08:56:56 <Alberth> are those industries serviced? 08:57:17 <andythenorth> maybe 08:57:34 <andythenorth> an industry that hasn't had service for 'n years' might be valid 08:57:54 <andythenorth> I would rather the game came by, and said 'I would like to put a flag on this industry for closure' and the newgrf said yes or no 08:58:10 <Alberth> hmm, interesting, as player I can postpone progress to newer industries by giving good service to existing ones 08:58:21 <andythenorth> the game could favour trying to close types which are over-represented 08:58:30 <andythenorth> but yes 08:58:32 <Alberth> I would like that 09:00:03 <andythenorth> I can't think of other options for total limit other than increasing it when a new type becomes available 09:00:25 <andythenorth> industry probability I don't really understand 09:00:26 <Alberth> we'd also need some switches for the player, I guess, like "passive" (don't close stuff that is serviced) to "agressive" (I don't care if I need to rebuild stations all the time due to closing industries) 09:00:57 <andythenorth> I would say that is a newgrf thing, except....default industries still need to work :| 09:01:23 <Alberth> increasing the limit works the same as reserving but not using target counts for them 09:01:41 <andythenorth> resp. probability....in my mind it should represent 'build this many on the smallest map size and scale linearly for larger maps' 09:01:51 <Alberth> but default industries are re-programmable :p 09:02:39 <Alberth> it does, except "smallest map size" is 256x256, ie for 64x64, the number gets divided 09:03:37 <Alberth> euhm, that is for the total number of industries, not for the probability of a single industry type 09:05:58 <Alberth> it works the other way around, you get a total count, deduct the forced industries, then add additional industries by drawing random numbers, where the probability of its type gives the (relative) likelyhood of picking that type. 09:06:32 <Alberth> so all probability 1 is the same as all probability 20 09:07:41 <Alberth> and probability 14 has twice as much chance to get picked as probability 7 09:07:49 <Alberth> s/as/than/ 09:16:27 <andythenorth> Alberth: the current probability - is that the optimal method? 09:17:37 <andythenorth> it's a PITA as a newgrf author 09:17:59 <andythenorth> increasing the probability at one industry means possibly adjusting *all* the other industry probabilities 09:18:05 <Alberth> depends on what you consider 'optimal' behaviour 09:18:40 <andythenorth> e.g. for a given map size, and setting, predictable number of arable farms irrespective of date 09:19:11 <andythenorth> from a newgrf author perspective 09:19:17 <Alberth> did you consider setting up something that expresses nicely what you want, and have it automagically translated to prob. numbers? 09:19:27 <andythenorth> no 09:20:00 <andythenorth> frosch and I did discuss new cb to allow newgrf to adjust probabilities 09:20:07 <andythenorth> currently they are fixed in action 0 09:20:22 <andythenorth> however it seems to be clunky compared to having the game sort it out 09:20:55 <Alberth> industry generation at startup is separate from in-game, with its own probs. Is that not enough to get some predictable number? 09:21:21 <andythenorth> no because of the absolute dates 09:21:29 <Alberth> ... 09:21:45 <andythenorth> so #arable farms if game started in 1830 is wildly different to number if game started in 1950 09:22:16 <Alberth> is that current behaviour, or wanted behaviour? 09:22:20 <andythenorth> current behaviour 09:22:43 <Alberth> how does that happen? 09:22:58 <andythenorth> so limit is say 27 09:23:10 <andythenorth> game tries to build 27 industries at start 09:23:17 <andythenorth> most types aren't available in 1830 09:23:23 <andythenorth> so you get a lot of the ones that are available 09:23:33 <andythenorth> test it :) 09:23:36 <Alberth> ah, indeed 09:23:45 <Alberth> my patch does the same 09:23:55 <Alberth> for in-game behavior 09:23:55 <andythenorth> it's why I think an absolute limit is dumb 09:24:03 <andythenorth> and basing it on 1950-2050 is also dumb 09:24:28 <andythenorth> (dumb for where we are now with newgrf industry, not dumb in 1994) 09:25:22 <andythenorth> it's also why I think probability should express number to be created on a certain size map, and limit should not be needed 09:26:26 <Alberth> that breaks the #of industries setting by the player 09:26:43 <Alberth> but more room for change would be nice 09:26:45 <andythenorth> scale it? 09:27:13 <andythenorth> probability = 256x256 map, 'normal' 09:27:30 <Alberth> I think that gets done 09:27:52 <andythenorth> yes looks like it 09:28:06 <Alberth> it might be not so bad to have many farms in 1830 09:28:25 <Alberth> the trouble that they don't go away to make room when needed 09:28:31 <Alberth> +is 09:28:49 <andythenorth> and also players who start later get far fewer farms, which causes multiple problems :) 09:29:47 <Alberth> this sounds like a contradiction 09:29:59 <andythenorth> ? 09:30:06 <andythenorth> possibly ;) 09:30:41 <Alberth> if you start early, you get more than you want, so they must be removed; if you start later, you want more 09:31:01 <Alberth> I think it is a sympton of a deeper issue 09:31:04 <andythenorth> yes. 09:31:15 <andythenorth> I don't think the contradiction here is mine (for once) :) 09:31:59 <andythenorth> excepting the route of a probability cb (which I think is overkill), here's what I think should happen.... 09:32:26 <andythenorth> newgrf author specifies 'probability' 4 for 256x256 map for Arable Farms 09:32:41 <andythenorth> on 'normal' game tries to build 4, irrespective of date 09:32:45 <Alberth> how does industry probs compare with vehicle life time? 09:33:11 <Alberth> (please continue your story) 09:33:48 <andythenorth> on 'low' game tries to build (4/2.25), irrespective of date (scale factor taken from current code) 09:34:18 <andythenorth> on 'high' game tries to build (4/0.625), irrespective of date 09:34:41 <andythenorth> on different size maps, scale factors also apply 09:35:02 <andythenorth> if game can't build 4, it needs to back off and not spend ages on map gen 09:35:17 <andythenorth> then keep trying to build every so often until total is 4 09:36:07 <andythenorth> interesting side effect: if game builds 4 arable farms at start, no more would be added later 09:36:26 <andythenorth> that might be unexpected 09:36:40 <andythenorth> it's nice to get a new coal mine or so every now and then :o 09:36:47 <andythenorth> but in FIRS' case new industry chains become available anyway 09:37:00 <andythenorth> and players can fund new industry - that's what all that money is for :P 09:37:08 <andythenorth> dunno about default case though 09:37:25 <andythenorth> frosch could probably tell me in one line why this is wrong approach :( 09:38:31 <Alberth> so we are discussing this at the wrong time :p 09:39:10 <andythenorth> dunno 09:39:19 <andythenorth> does my idea make sense to you? 09:40:48 <Alberth> you seem to be thinking in absolute numbers rather than probabilities 09:41:05 <Alberth> I need to think about it for a while 09:43:24 <Alberth> what sort of confuses me is the problem of goal. How should industries behave in general for a player to enjoy the game. 09:44:02 <Alberth> and it seems that reserving target counts for not-yet-available industry types might be a nice experiment. 09:44:26 <Alberth> we may even not need gradually increasing industry counts then 09:46:49 <Alberth> default industries only have the oilrig that becomes available later? 09:49:11 <andythenorth> Alberth: yes, the oil rig only IIRC 09:49:52 <Alberth> what bothers me in current trunk is that you get an insane number of industries at the start of the game (for larger maps and high industry count settings). You are never ever going to connect them all in 5 years. So you get this waves of closing and opening. Reserving for not-yet-available industry types would be a nice way to reduce the initial industry count 09:50:49 <Alberth> so for default industries it won't work :) 10:09:28 *** KenjiE20 has joined #openttdcoop.devzone 10:32:04 <andythenorth> Alberth: sorry I was afk 10:32:28 <andythenorth> interesting point about default industries - an overwhelming number at start, then they all close is exactly true 10:32:48 <andythenorth> same for FIRS for a later start date (except I did something to limit closures) 10:37:10 <andythenorth> I'm out for a bit now :) 10:53:22 <Alberth> np, I tend to walk away at random moment too :) 11:42:39 *** ODM has quit IRC 12:37:32 *** Seberoth has joined #openttdcoop.devzone 12:41:58 *** Seberoth_ has quit IRC 13:22:21 <Brot6> 32bpp-ez-patches - Feature #1468 (New): Profile and optimize CC blending algorithm (GeekToo) @ http://dev.openttdcoop.org/issues/1468 13:26:02 <Brot6> 32bpp-ez-patches - Feature #1468: Profile and optimize CC blending algorithm (GeekToo) @ http://dev.openttdcoop.org/issues/1468#change-3918 13:27:17 *** GT has joined #openttdcoop.devzone 13:28:22 <GT> ^Anyone up for some test runs, to gather some data on different architectures? See the issue above ^^^ 13:31:30 <Rubidium> yes... just not any time soon :( 13:36:34 *** frosch123 has joined #openttdcoop.devzone 13:40:26 <GT> no problem, there are probably more people that can run three commands. 13:44:38 <SmatZ> GT: floats :-x 13:44:59 *** Yexo has quit IRC 13:45:12 *** Yexo has joined #openttdcoop.devzone 13:45:14 <SmatZ> GT: why are you testing without optimisations enabled? 13:45:37 <SmatZ> the results with -O2 might differ a lot 13:45:48 <SmatZ> or even, with -O3 13:46:06 <SmatZ> /tmp/ccegy3Dg.o:(.eh_frame+0x12): undefined reference to `__gxx_personality_v0' 13:46:12 <SmatZ> guess g++ should be used :) 13:49:22 <SmatZ> GT: how long should the test take? 13:49:50 <SmatZ> user 2m2.860s 13:49:51 <SmatZ> :x 13:53:04 <GT> Smatz: the optimize flag on my system (Gentoo) are set in the make.conf file, it is set to O2, but you're right, that should be added to the command to have comparable results 13:53:58 <GT> And the intention is to weed out the floats again that Szvengar introduced some time ago. 13:54:17 <SmatZ> GT: make.conf is not used for regular compiling, only for portage compiling 13:54:43 <SmatZ> with -O2, the test finishes in zero time 13:54:50 <SmatZ> because it's completely optimised away 13:55:17 <SmatZ> GT: http://nopaste.info/82130f411d.html something like this prevents it from being optimised away 13:55:19 <Webster> Title: nopaste.info - free nopaste script and service (at nopaste.info) 13:57:28 <SmatZ> marking those functions noinline/noclone is probably better 13:57:39 <SmatZ> or they might be inlined and the loop unrolled 13:57:57 <SmatZ> giving unusable benchmark results 13:58:24 <GT> Maybe, but ingame they're also used inline, don't know how that influences the measurements. 13:59:44 <GT> There's still room for more improvement, the lightness_colour does not need to be set if the saturation is not 0 14:02:49 <SmatZ> GT: they are used inline, but are they used with constant parameters? 14:02:58 <SmatZ> as in your benchmark 14:03:31 <SmatZ> when foo(int a, int b) { return a+b; } gets inlined with constant parameters foo(2,3), it's just "5" 14:03:46 <SmatZ> not "eax=2, ebx=3, eax+=ebx" 14:05:12 <GT> there not, they're fed with the pixel value of the sprite, and the remap colour, so not constants. 14:46:37 <GT> gcc -O2 -Wall test_prof.cpp, and then time ./a.out original algorithm: 14:46:40 <GT> real 0m10.014s 14:46:40 <GT> user 0m9.777s 14:46:40 <GT> sys 0m0.012s 14:47:07 <GT> and with the new algorithm:real 0m1.760s 14:47:07 <GT> user 0m1.720s 14:47:07 <GT> sys 0m0.000s 14:47:57 <GT> -pg combined with -O2 did not work out very well, like no results for the functions, or a never returning app. 14:48:34 <GT> measured this way, it looks like the new one is also a lot faster. 14:53:07 <Ammler> Rubidium: releases don't have version in findversion.sh, where do you extract it there, from config.lib? 14:57:50 <Rubidium> the tag 15:00:52 <Ammler> and the he repos always have the modified flag set? 15:00:58 <Ammler> hg* 15:02:11 <Rubidium> releases aren't in the hg repository 15:02:45 <Ammler> yeah, I know, they need the release changest 15:03:09 <Ammler> I just wonder, how "safe" it would be to publish such binaries 15:03:41 <Ammler> like the bilbo client patch pack some time ago 15:26:50 <SmatZ> GT: the loop will never finish 15:26:53 <SmatZ> typedef int uint32; 15:26:55 <SmatZ> because of this 15:27:07 <SmatZ> and 0xF0FFFFFF is unsigned constant 15:27:20 <SmatZ> for some reason, it finishes with <gcc-4.3 15:27:35 <SmatZ> ("undefined behaviour" I suppose) 15:29:26 <SmatZ> comparing uint with int is funny 15:29:27 <SmatZ> like... 15:29:32 <SmatZ> what is the result of 15:29:39 * Alberth ponders how to test the 'split townnames' nml patch further 15:29:41 <SmatZ> (unsigned) > -3 15:29:43 <SmatZ> ? 15:30:18 <Alberth> it's widened to uint, afaik 15:30:30 <Ammler> Alberth: If you like to continue that, I would split it to parts with same probability 15:30:58 <Alberth> bummer, I have already something much more advanced :( 15:31:00 <Alberth> :p 15:31:11 <Ammler> ok :-) 15:31:13 <SmatZ> Alberth: actually, it returns always false 15:31:29 <Ammler> I just found out, that is actually "wrong" in my splitting :-) 15:31:35 <SmatZ> funny thing is, (unsigned) >= -3 returns true when (unsigned) == (unsigned)(-3) 15:31:43 <SmatZ> might be undefined behaviour, again 15:31:55 <SmatZ> but the behaviour of gcc is strange 15:32:10 <Alberth> SmatZ: weird, i'd expect 0xffffffff > (uint)(-3) 15:32:17 <SmatZ> Alberth: yeah, so would I :) 15:32:26 <SmatZ> I couldn't find anything about that in the standard 15:32:36 <SmatZ> so I gave up filling a bug report 15:50:45 <GT> Smatz, I already found that define, and fixed it. Still, with -O flags, no decent profile can be generated (i.e. with the 2 interesting functions mentioned in it), so I switched to the time method, and commenting out one of the function calls. 15:52:05 <Brot6> NewGRF Meta Language - Revision 757:e77af56d5f6a: Add: Vehicle variable 0x25 (grfid) (Hirundo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/e77af56d5f6a 15:52:05 <Brot6> NewGRF Meta Language - Revision 758:0109924fd504: Add: Vehicle variables 0xBA / 0xBC (cargo_capac... (Hirundo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/0109924fd504 15:52:05 <Brot6> NewGRF Meta Language - Revision 759:460530251feb: Codechange: Generalize the sign-extension code ... (Hirundo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/460530251feb 15:52:07 <Brot6> NewGRF Meta Language - Revision 756:e1f94f674741: Add: Vehicle variable 0x5F (waiting_triggers / ... (Hirundo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/e1f94f674741 15:52:11 <Brot6> NewGRF Meta Language - Revision 760:e7d2c216acad: Add: A few vehicle_is_xxx vehicle variables. (Hirundo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/e7d2c216acad 15:52:15 <Brot6> NewGRF Meta Language - Revision 761:80d8d5e70812: Add: Two breakdown-related vehicle variables (r... (Hirundo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/80d8d5e70812 15:57:02 <Brot6> NewGRF Meta Language - Bug #1469 (New): documentation about 'graphics' is wrong (Hirundo) @ http://dev.openttdcoop.org/issues/1469 15:58:20 <Brot6> OpenGFX - Bug #1470 (New): makefile issues (Ammler) @ http://dev.openttdcoop.org/issues/1470 16:06:34 <Alberth> 2 new features arrived :) 16:07:18 <Alberth> pom tie pom 16:08:07 <Brot6> NewGRF Meta Language - Revision 763:39a8f6242f79: Codechange: Allow creation of several ActionFs ... (Alberth) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/39a8f6242f79 16:08:07 <Brot6> NewGRF Meta Language - Revision 762:e76ae4ee50de: Codechange: Move check of 255 pieces limit, exp... (Alberth) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/e76ae4ee50de 16:08:07 <Brot6> NewGRF Meta Language - Revision 765:342d89caaeca: Feature: Implement creation of multiple ActionF... (Alberth) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/342d89caaeca 16:08:09 <Brot6> NewGRF Meta Language - Revision 764:41be407e8a2e: Feature: Drop names with 0 probability. (Alberth) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/41be407e8a2e 16:09:16 <Alberth> very useful order, Brot6 :) 16:09:44 <Ammler> I would guess, that was you :-) 16:10:09 <Alberth> of course, I always commit in non-increasing order :) 16:11:19 <Ammler> how do you commit 4 changesets in same sec? 16:11:40 <Ammler> or why do you fix the time? 16:11:49 <Alberth> hg import *.patch 16:12:37 <Alberth> straight from the mq of another clone 16:12:56 <Ammler> you know qfinish? 16:13:20 <Alberth> not really, but then the patch ends up in the wrong clone 16:13:58 <Ammler> well, but so, you still have the patch in the other clone which conflicts with next pull 16:15:00 <Hirundo> I usually just make a series of mq patches, then 'hg qfinish -a' and 'hg push' 16:15:18 <Ammler> anyway, it should be possible to add the rev to the sorting too 16:15:25 <Alberth> I first make a new clone, and work in there 16:16:19 <Alberth> in that way, I can work on more things, and/or keep something for a longer time without having it to store somewhere 16:17:40 <Alberth> eg in openttd I have some 20 clones 16:17:49 <Alberth> anyway, time for some food 16:18:28 <Hirundo> even then, you could 'hg push' to your main repo 16:21:18 <Brot6> nforenum.data: compile of r486 failed - http://bundles.openttdcoop.org/nforenum.data/nightlies/ERROR/r486 16:22:13 <Brot6> nml: update from r751 to r765 done - http://bundles.openttdcoop.org/nml/nightlies/r765 16:22:29 <Brot6> Following repos didn't need a nightlies update: 2cctrainset (r613), 32bpp-extra (r39), airportsplus (r59), basecosts (r20), belarusiantowns (r7), comic-houses (r71), firs (r1361), fish (r390), frenchtowns (r4), grfcodec (r253), heqs (r372), metrotrackset (r56), newgrf_makefile (r184), nforenum (r502), nutracks (r115), ogfx-test (r529), ogfx-trees (r15), ogfxplus (r42), opengfx (r535), openmsx (r97), opensfx (r97), snowlinemod (r42), 16:22:29 <Brot6> swedishrails (r156), swisstowns (r14), transrapidtrackset (r15), ttdviewer (r25), ttrs (r18), worldairlinersset (r663) 16:23:47 <Brot6> 2cc train set - Bug #1471 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/1471 16:24:23 <Brot6> 32bpp-extra - Bug #1472 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/1472 16:24:58 <Brot6> Base Costs Mod - Bug #1473 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/1473 16:24:58 <Brot6> Belarusian Town Names - Bug #1474 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/1474 16:24:58 <Brot6> Comic Style Houses - Bug #1475 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/1475 16:26:15 <Brot6> FISH - Bug #1476 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/1476 16:26:15 <Brot6> French Town Names - Bug #1477 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/1477 16:26:51 <Rubidium> yay for automated bug filing 16:27:09 <Rubidium> "oops" Ammler made a mistake and there'll be 20 bug reports scattered around 16:27:37 <Brot6> HEQS "Heavy Equipment" Set - Bug #1478 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/1478 16:27:37 <Brot6> Metro Track Set - Bug #1479 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/1479 16:27:37 <Brot6> Nutracks - Bug #1480 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/1480 16:27:44 <Ammler> yes, that sucks :-) 16:28:36 <Ammler> and what was the mistake? 16:29:04 <SmatZ> [17:31:35] <SmatZ> funny thing is, (unsigned) >= -3 returns true when (unsigned) == (unsigned)(-3) <== interesting, I can't find the original testcase anymore 16:29:12 <SmatZ> and I can't reproduce it... 16:29:19 <SmatZ> so maybe I lied to you, Alberth, sorry 16:29:46 <Ammler> why does it rebuild 2cctrainset? 16:30:02 <andythenorth> evening 16:30:22 <SmatZ> hello andythenorth 16:30:31 <Ammler> heya :-) 16:30:44 <Ammler> the project which failed seem very randomly 16:31:00 <Brot6> OpenGFX+ - Bug #1481 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/1481 16:31:33 <Rubidium> Ammler: it smells like it's recompiling everything 16:31:36 <Ammler> ah no, nfo projects 16:31:41 <Rubidium> and that the spec's broken 16:33:05 <Ammler> ah, I see 16:33:16 <Ammler> but I can't remember that I changed that :-o 16:33:27 <Ammler> looks like nml is default type 16:33:40 <Brot6> Snowline mod - Bug #1482 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/1482 16:34:53 <Brot6> Swedish Rails - Bug #1483 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/1483 16:34:53 <Brot6> Swiss Town Names - Bug #1484 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/1484 16:34:53 <Brot6> TransRapid Track Set - Bug #1485 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/1485 16:34:53 <Brot6> Total Town Replacement Set - Bug #1486 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/1486 16:35:22 <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: airportsplus, firs, newgrf_makefile, ogfx-test, ogfx-trees, opengfx 16:36:15 <Ammler> that was really confusing :-o 16:36:50 <Ammler> and my assumption is wrong 16:36:51 <Brot6> World Airliners Set - Bug #1487 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/1487 16:39:28 <Ammler> ha, it is because the enabled stats :-) 16:42:31 <andythenorth> Alberth: any more thoughts on industry control? 16:46:16 <Ammler> ok, fixed and sorry in advance :-) 16:46:35 * Ammler is deleting the tickets assigned to him... 16:48:08 <Brot6> OpenGFX+ Airports - Bug #1467 (Closed): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/1467 16:48:08 <Brot6> OpenGFX+ Airports - Revision 59:b69876cf0101: Fix #1467: we need to set build type for non nfo pr... (Ammler) @ http://dev.openttdcoop.org/projects/airportsplus/repository/revisions/b69876cf0101 16:48:09 <Brot6> OpenGFX+ Airports - Bug #1467 (Closed): DevZone compile failed (Ammler) @ http://dev.openttdcoop.org/issues/1467#change-3915 16:48:09 <Brot6> FIRS Industry Replacement Set - Feature #1466: Consider if Machine Shop should accept MNSP (andythenorth) @ http://dev.openttdcoop.org/issues/1466#change-3917 16:48:11 <Brot6> 2cc train set - Bug #1471 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/1471 16:48:51 <Brot6> AP+ MQ - Revision 2:01a5b85148bb: Add set welcome location (Ammler) @ http://dev.openttdcoop.org/projects/autopilot-mq/repository/revisions/01a5b85148bb 16:49:42 <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: belarusiantowns (3 errors) (Diffsize: 21), frenchtowns (4 errors) (Diffsize: 9), ogfxplus (Diffsize: 6), swedishrails (Diffsize: 6), swisstowns (4 errors) (Diffsize: 9) 16:50:40 <Ammler> this time, I let people find out self, that the compile error isn't their own fault :-) 16:53:22 <Alberth> SmatZ: np :) 16:54:53 <Alberth> andythenorth: not really, town names were more important. Reserving counts for unavailable industries still seems interesting though. 16:55:38 <Alberth> I just hope I can get a non-zero probability for them 16:58:09 <andythenorth> Alberth: the effect should come out the same in the end as what I proposed earlier 16:59:29 <andythenorth> if counts are reserved, then (in the example) fewer farms would be built in 1830 16:59:36 <Brot6> feed NewGRFs had 11 updates, showing the latest 10 16:59:37 <Brot6> OpenGFX+ Airports - Revision 56:5b4be78d2d36: Change: switch to nml, delete all old nfo files (yexo) @ http://dev.openttdcoop.org/projects/airportsplus/repository/revisions/5b4be78d2d36 16:59:37 <Brot6> OpenGFX+ Airports - Revision 57:31d5d352499d: Add: nml code for small airport (yexo) @ http://dev.openttdcoop.org/projects/airportsplus/repository/revisions/31d5d352499d 16:59:37 <Brot6> OpenGFX+ Airports - Revision 58:784777d5ba42: Fix: remove superfluous spaces from custom_tags.txt (yexo) @ http://dev.openttdcoop.org/projects/airportsplus/repository/revisions/784777d5ba42 16:59:39 <Brot6> FIRS Industry Replacement Set - Revision 1359:01ad3106d0d9: Fix: Paper Mill didn't accept Clay on... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/01ad3106d0d9 16:59:43 <Brot6> FIRS Industry Replacement Set - Feature #1462 (New): No more changes to cargo chains until econom... (andythenorth) @ http://dev.openttdcoop.org/issues/1462 16:59:45 <Alberth> andythenorth: indeed 16:59:46 <Brot6> FIRS Industry Replacement Set - Feature #1463 (New): Consider merging Bakery and Windmill to Grai... (andythenorth) @ http://dev.openttdcoop.org/issues/1463 16:59:49 <Brot6> FIRS Industry Replacement Set - Revision 1360:ee605b924118: Feature: Paper Mill accepts Chemicals (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/ee605b924118 16:59:53 <Brot6> FIRS Industry Replacement Set - Revision 1361:9083591f3677: Feature: update industry window texts... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/9083591f3677 16:59:56 <andythenorth> brot is somewhat behind? 16:59:58 <Brot6> FIRS Industry Replacement Set - Feature #1463: Consider merging Bakery and Windmill to Grain Mill (andythenorth) @ http://dev.openttdcoop.org/issues/1463#change-3912 17:00:00 <Brot6> FIRS Industry Replacement Set - Feature #1466 (New): Consider if Machine Shop should accept MNSP (andythenorth) @ http://dev.openttdcoop.org/issues/1466 17:00:01 <andythenorth> brr 17:00:12 <Ammler> deleted the faulty tickets... 17:00:29 <Alberth> limiting to 5 would be sufficient, I think 17:01:52 <Ammler> hmm, if I would know, how to change that :-) 17:04:27 <Hirundo> Yexo: What is the speed unit for aircraft in openttd? 17:04:30 <Alberth> oh, it is bot setting, not a RM setting 17:04:45 <Yexo> Hirundo: I don't know, I'll take a look 17:04:53 <Yexo> most likely the same as in the action0properties 17:05:03 <Hirundo> I suspect it is not the mph*8 as stated in the 80+x specs 17:05:34 <Brot6> OpenGFX - Bug #1470: makefile issues (Ammler) @ http://dev.openttdcoop.org/issues/1470#change-3919 17:06:21 <Ammler> is it possible to change a file during make? 17:06:51 <Ammler> like adding something to custom_tags after nmlc 17:07:06 <Yexo> yes, but that'll break make probably 17:07:11 <Yexo> or at least leat to unexpected results 17:07:36 <Rubidium> internally OpenTTD uses 1 unit = 1 km-ish/h, but it reads 1 unit = 8 mph from a NewGRF 17:08:26 <Rubidium> doesn't seem that the action2 stuff converts it back to mph/h for aircraft though 17:08:38 <Yexo> case 0x34: return v->cur_speed; 17:08:45 <Yexo> it returns the internal value 17:09:43 * Rubidium blames Celestar :) 17:11:37 <Alberth> andythenorth: an interesting problem is a unbuildable not-yet-available industry type 17:16:10 <Hirundo> Yexo: Shall I make a patch for it? 17:16:20 <Yexo> Hirundo: yes please :) 17:16:27 <Yexo> I'm still searching for when it changed 17:17:24 <andythenorth> Alberth: interesting in what respects? 17:18:01 <Hirundo> Will take some time though, dinner is higher up my priority list 17:18:32 <Alberth> andythenorth: it would be a waste not to use that room for other industries 17:18:48 <andythenorth> how do you know it's unbuildable? 17:19:07 <Alberth> try building it, and fail :) 17:19:30 <Alberth> except you can only do that when the industry becomes available :( 17:20:09 <Alberth> hmm, I *could* use test-mode :p 17:20:30 <andythenorth> also it might be buildable if player terraforms 17:20:38 <andythenorth> or if a town expands 17:20:43 <andythenorth> or for other reasons 17:21:16 <Alberth> hmm, so even if it is not buildable now, it should continue to try? 17:21:20 <Alberth> nasty 17:21:43 <andythenorth> it is a thorny problem :) 17:25:30 <andythenorth> currently some things that should be controlled better by newgrf are not, and some things that would be better controlled by game are done with newgrf 17:35:47 <Alberth> that is to be expected over such a long period with both sides continuously changing :) 17:48:20 <andythenorth> Alberth: if it stops trying to build an unbuildable, does that free a space for another industry? 17:48:25 <andythenorth> your patch backs off yes? 17:49:26 <Alberth> those are two unrelated questions atm 17:50:18 <andythenorth> ok 17:50:49 <Alberth> to start with the second one, yes, if an attempt fails, wait_count = max_wait; max_wait +=2 ; while wait_count > 0: 'I am not available' ; wait_count-- 17:51:18 <Alberth> as wait_count gets an increasing value, it takes longer and longer before another attempt is donw 17:52:49 <Alberth> so, currently it never stops trying, but the industry type becomes unavailable for building for some time, and another industry is chosen instead 17:54:05 <Alberth> for the first question, now if I reserve some count for an industry type, and it cannot be build, I would like to free those spaces gradually for other industries 17:54:24 <andythenorth> can the same mechanism for backing off eventually also free the space? 17:54:38 <Alberth> probably it can 17:55:13 <andythenorth> unbuildable due to cb22 or b28? 17:55:18 <andythenorth> cb28 /s 17:55:22 <Alberth> in some modified form, as max_wait now has no upper limit 17:56:11 <Alberth> sorry I don't speak cbs :) 17:56:49 <andythenorth> cb22 is availability 17:57:00 <andythenorth> cb28 is whether construction is permitted or not 17:57:09 <Alberth> cb28 17:57:17 <andythenorth> ok 17:57:21 <andythenorth> that makes sense 17:57:24 <Alberth> ie I try to build it, and it fails 17:57:32 <andythenorth> afk 10 mins 18:01:22 <Brot6> 32bpp-ez-patches: update from r20786 to r20789 done (2 errors) - http://bundles.openttdcoop.org/32bpp-ez-patches/testing/r20789 18:10:38 <Brot6> serverpatches: update from r20786 to r20789 done (4 errors) - http://bundles.openttdcoop.org/serverpatches/testing/r20789 18:10:57 <Brot6> 32bpp-extra - Bug #1472: DevZone compile failed (GeekToo) @ http://dev.openttdcoop.org/issues/1472#change-3920 18:12:33 <Brot6> 32bpp-extra - Bug #1472: DevZone compile failed (GeekToo) @ http://dev.openttdcoop.org/issues/1472#change-3921 18:16:15 <Ammler> GT: yes, close it 18:16:16 <andythenorth> Alberth: the other route to explore is the one suggested by frosch123 - cb for newgrf to control probability 18:16:19 <Ammler> I can't 18:16:31 <Ammler> too late 18:18:45 <Ammler> he, I can't close, but I can delete 18:21:07 <Ammler> andythenorth: double post in FISH? 18:21:14 <andythenorth> ? 18:21:16 * andythenorth checks 18:21:39 <andythenorth> silly old forum :P 18:22:01 <Ammler> :-) 18:22:04 <Brot6> 32bpp-ez-patches - Feature #1468: Profile and optimize CC blending algorithm (GeekToo) @ http://dev.openttdcoop.org/issues/1468#change-3923 18:23:35 <Alberth> that was here afaik 18:23:42 <Alberth> unless it is much older 18:23:51 <Brot6> 32bpp-ez-patches - Feature #1468: Profile and optimize CC blending algorithm (Ammler) @ http://dev.openttdcoop.org/issues/1468#change-3924 18:25:24 <Alberth> but it makes things more complicated rather than less complicated 18:25:27 <frosch123> andythenorth: reading back... isn't the problem about industries with location conditions which cannot be met anywhere. e.g. a big 8x8 flat area on a mountainuous map? 18:25:38 <frosch123> what would probabilities help there? 18:25:43 <andythenorth> they wouldn't 18:25:49 <andythenorth> not at all 18:26:35 <Alberth> also, changing priorities is not much use if old industries don't die 18:27:12 <andythenorth> "old industries never die" 18:27:17 <andythenorth> :P 18:27:45 <Alberth> frosch123: you read back from 10.00 am this morning? we had a long and interesting discussion about industries :) 18:27:58 <Brot6> 32bpp-ez-patches - Feature #1468: Profile and optimize CC blending algorithm (GeekToo) @ http://dev.openttdcoop.org/issues/1468#change-3925 18:28:21 <frosch123> haha, no, i started 19:11 or so :) 18:28:47 <Ammler> http://dev.openttdcoop.org/attachments/944/custom_tags_for_all.diff <-- what is wrong here? (scripts/Makefile.common:82: *** commands commence before first target. Stop.) 18:28:49 <Brot6> OpenGFX - Bug #1470: makefile issues (Ammler) @ http://dev.openttdcoop.org/issues/1470#change-3926 18:28:55 *** ODM has joined #openttdcoop.devzone 18:30:30 <Alberth> indent of line 81 correct? 18:31:17 <Ammler> does that matter? 18:31:26 <frosch123> yes 18:31:44 <frosch123> you have to use tabs for make 18:33:29 <Ammler> oh, there is a missing doublequote on 80 18:34:27 <Ammler> he, this was it 18:34:28 <andythenorth> frosch123: 'fixing' industry generation would be worthwhile. Alberth has some good ideas; mine probably less so :P 18:34:54 <Ammler> that indent was some c&p issue 18:35:56 <Ammler> does `` work for "sub shell" in make? 18:36:11 <frosch123> andythenorth: no idea, i only got that far that alberth lets the grf specify the ratio of industries in game rather than the probability of creation, which seems to be more clever in any case :) 18:36:55 <andythenorth> is the current probability model a smart thing that I just don't understand? As it seems quite dumb to me :) 18:37:05 <frosch123> it just needs some playtests, as running an empty game with all industries unserviced is not exactly the same 18:39:56 <Ammler> IFS=$'\n' -> $$'\n' 18:57:31 <Brot6> 32bpp-ez-patches - Revision 63:632bbfcc8d25: Codechange: optimize CC blend in blitter #1468 (GeekToo) @ http://dev.openttdcoop.org/projects/32bpp-ez-patches/repository/revisions/632bbfcc8d25 18:57:32 <Brot6> 32bpp-ez-patches - Revision 64:d802a1bd33c3: Add: enable push build (GeekToo) @ http://dev.openttdcoop.org/projects/32bpp-ez-patches/repository/revisions/d802a1bd33c3 19:05:57 <Brot6> 32bpp-ez-patches: update from to r64 done (2 errors) - http://bundles.openttdcoop.org/32bpp-ez-patches/push/r64 19:08:12 <Brot6> 32bpp-ez-patches - Bug #1488 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/1488 19:09:44 <Hirundo> Yexo: http://pastebin.com/1KEDxmpK <- vehicle speed patch 19:11:04 <Hirundo> I've taken the liberty to use cached_max_speed instead of max_speed for trains as the latter stores only the current speed limit 19:11:07 <Ammler> hmm 19:12:55 <GT> r64? 19:13:31 <Ammler> that is the rev of the mq 19:14:57 <Ammler> the push worked 19:15:06 <Ammler> I have no idea, why it also tried a release 19:30:09 <Hirundo> hmm... don't vehicles move in really large steps, when viewed with 32bpp-EZ? 19:32:57 <Brot6> NewGRF Meta Language - Revision 766:545b5842fb90: Doc: Update the doc with the new feature of all... (Alberth) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/545b5842fb90 19:37:27 <GT> Hirundo, yes. 19:38:00 <GT> 16 steps a tile, iirc, only the tiles are 4 times larger 19:38:28 <Hirundo> I was thinking about the possibility to use vehicle 'progress' to smoothen that 19:40:24 <GT> explain the vehicle progress 19:43:02 <Hirundo> vehicles measure their movements in 1/256th of a single visible step 19:45:44 <GT> well, that has potential then. 19:47:05 <Ammler> GT, pushes will now apply to testing too 19:47:12 <Ammler> with the rev of openttd 19:47:52 <frosch123> Hirundo: expect jumping vehicles when starting/stopping and such 19:48:33 <frosch123> progress also depends on vehicle orientation in some cases 19:52:17 <Hirundo> I'd expect it to be orientation-dependant, that should be no problem 19:54:20 <Brot6> NewGRF Meta Language - Feature Request #1327: allow more than 255 names (Alberth) @ http://dev.openttdcoop.org/issues/1327#change-3927 19:54:26 <Hirundo> I do wonder, why progress is set to a hardcoded value when waiting for a signal 19:55:13 <GT> Ammler: thnx 19:55:17 <frosch123> else slow accelerating trains will never make it past the signal 19:55:30 <Brot6> 32bpp-ez-patches: update from r20789 to r20791 done (2 errors) - http://bundles.openttdcoop.org/32bpp-ez-patches/testing/r20791 19:56:25 <frosch123> similiar is done for roadvehicles when blockes 19:57:56 <Hirundo> It should be no visible issue for RVs, because the actual moved distance is always less than the vehicle would "want to" 20:00:39 <Brot6> OpenGFX - Bug #1470: makefile issues (Ammler) @ http://dev.openttdcoop.org/issues/1470#change-3928 20:04:27 <Ammler> Alberth: are you able to tell, how you split the lists? 20:04:39 <Ammler> town names > 255 entries 20:04:52 <Alberth> you really want to know? :) 20:05:15 <Ammler> so you aren't :-P 20:05:33 <Alberth> yes I am, it is just a bit complicated 20:06:08 <Ammler> I try to read the source 20:06:16 <Alberth> 1. decide how many sub-lists are needed by virtually moving elements in new sub-lists 20:07:40 <Alberth> with source it is easier :) 20:08:08 <Alberth> 166-177 collect elements that can be moved, and order them by their probability value 20:08:16 <planetmaker> good evening 20:08:53 <Alberth> 183-201 decide how many sub-action F there are needed 20:08:58 <Terkhen> hi planetmaker 20:08:59 <Alberth> evening planetmaker 20:09:36 <Alberth> 'split_pieces' at 203 then does the actual moving 20:10:06 <Ammler> so "recalculate" the probability? 20:10:08 <Alberth> and since the actual move is slightly different than my calculation, I try again with nactf+1 at line 207 20:10:12 <planetmaker> anything I missed and should read logs about? :-) 20:10:45 <Alberth> an interesting discussion about industry generation between me and andy 20:11:08 <andythenorth> hi planetmaker 20:11:17 <andythenorth> also I rebuilt FIRS cargo chains :P 20:11:20 <Alberth> are you following town-name limitations of NML? 20:11:21 <planetmaker> ah :-) about your new patch? 20:11:36 <planetmaker> town name limitations? Never heart that... 20:11:52 <Alberth> more about further steps that would be useful 20:12:24 * andythenorth wants to be able to plant rock tiles around industries 20:12:37 <planetmaker> hm... is there any logs available here, Ammler ? 20:12:38 <Alberth> Ammler: 212-226 then create the new action F, and a reference to that action in the original set 20:12:47 <Ammler> @logs 20:12:47 <Webster> Logs: http://hyru.ath.cx:60080/~kenji/ottdcoop/ 20:12:51 <planetmaker> :-D 20:12:55 <planetmaker> webster's back! 20:13:07 <Ammler> :-) 20:13:32 <Ammler> Alberth: I could also compare the nfos 20:13:39 <Terkhen> all issues with mingw (besides those related to nml) have a diff file to fix them, but some of them need a bit of discussion 20:13:55 <planetmaker> oh, nice, too :-) 20:14:37 <Terkhen> after applying the missing patches to opengfx it compiles fine, I have not checked if the MD5 are the same but they should 20:14:54 <planetmaker> sweet :-) 20:14:59 <Ammler> and I started with the generic sed and custom_tags in the Makefile (#1470), but failed :-P 20:15:00 <Brot6> Ammler: #1470 is http://dev.openttdcoop.org/issues/show/1470 "OpenGFX - Bug #1470: makefile issues - #openttdcoop Development Zone" 20:15:21 <Brot6> FIRS Industry Replacement Set - Revision 1362:451f0f64872e: Fix: Retail Market typo (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/451f0f64872e 20:15:21 <Brot6> FIRS Industry Replacement Set - Revision 1363:c78033a373c7: Add: graphics files for Brick Works (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/c78033a373c7 20:15:34 <Alberth> hmm, is there also actual text in the log? 20:15:54 <planetmaker> how do you mean, Alberth ? 20:16:15 <Hirundo> Alberth: Now try writing the same town name code in C (not c++) :) 20:16:36 <Alberth> I only get some messages about people leaving, joining, and mode changes 20:17:02 <Alberth> Hirundo: I would fix the stupid 255 limit :) 20:17:11 <planetmaker> http://hyru.ath.cx:60080/~kenji/ottdcoop/?channel=openttdcoop.devzone&date=1284274800 <-- like that page, Alberth ? 20:17:35 <Ammler> Alberth: it's not #openttdcoop.dev 20:17:44 <planetmaker> btw... anybody care to give a brief summary of the industry discussion? It's lengthy... 20:18:33 <Ammler> hmm, #openttd gets some attacks this evening 20:19:02 <andythenorth> Alberth is probably better placed to explain what could be done? 20:19:03 <Alberth> Ammler: indeed, it is not :) thanks 20:19:46 <Alberth> hmm, let's see.. 20:21:05 <Alberth> the trouble currently seems to be that during game generation, the available industries at that time are used to create a world 20:21:30 <planetmaker> jo 20:21:43 <frosch123> Alberth: please just ignore sirkoz :) 20:22:10 <Brot6> FIRS Industry Replacement Set - Revision 1364:79d36c92ff2c: Change: start providing correct graph... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/79d36c92ff2c 20:22:12 <Alberth> that means there is no room left for industries that become available later 20:22:43 <frosch123> only if none close 20:22:53 <Alberth> frosch123: oh the toggle you mean? I have no problems with it, but I am not even considering trunk inclusion yet :) 20:23:05 * andythenorth has some problems with it :P 20:23:23 * Terkhen wonders if all settings for new features to go back to the old behaviour have been suggested by sirkoz 20:23:38 <Alberth> it also leads to some balancing problems, depending on the year you start, the mix of industries changes 20:24:05 <Alberth> Terkhen: search for 'sirkoz' and 'toggle' :p 20:24:30 <Terkhen> :) 20:24:34 <planetmaker> hm... is that really a problem, that new industries become available? 20:24:46 <frosch123> Alberth: how about the old idea to create at least 2% * (industries at map creation) industries per year 20:24:54 <frosch123> even if enough are on the map 20:25:21 <Alberth> so as a next experiment, the idea is to reserve space for future available industries but not build them 20:25:23 <andythenorth> planetmaker: it is a problem that new industries become available 20:25:44 <andythenorth> planetmaker: start a FIRS game in 1830 and count farms, then try a new game in 1970 and count farms.... 20:25:45 <Alberth> frosch123: GetNumberOfIndustries does a linear increase of wanted number of industries 20:25:53 <Alberth> although it is a lot less than 2% :) 20:25:54 <frosch123> planetmaker: imagine those weird players disabling all industry closure and then complain about no aluminium plants in 2000 20:25:54 <planetmaker> I guess I need to understand that in the first playe: why is a difference a problem? 20:26:18 <planetmaker> frosch123: hm... would new ones only open, if old ones close? 20:26:19 <frosch123> Alberth: does it do that wrt. playing time? 20:26:32 <frosch123> i.e. also if enough industries close down? 20:26:49 <Alberth> between 2 fixed years (1950 and 2050) 20:26:58 <andythenorth> planetmaker: the problem is providing a balanced set for players who start at different dates 20:27:29 <frosch123> i guess that is the most weird point of the patch for me :) there should be a difference between an empty map without any serviced industries, and a map with all industries serviced 20:27:32 <Alberth> industry close down has nothing to do with increasing number of industries (assuming the patch can keep up) 20:27:53 <frosch123> in the latter case new industries should appear, in the former i would not mind them closing 20:28:05 <planetmaker> I my assumption correct that closure and opening are completely independent by default? 20:28:39 <Alberth> opening is controlled by the game, shutdown is controlled by the industry 20:29:00 <andythenorth> we mostly discussed opening 20:29:10 <andythenorth> closing is linked, but not the same issue... 20:29:19 <Alberth> frosch123: unserviced industry may close, I just create new ones at the same rate (hopefully) 20:29:28 <planetmaker> ok, my understanding of Albert's patch is, that it tries to open those industries which are missing most wrt the intended probabilities 20:29:40 <andythenorth> it does indeed do that :) 20:29:43 <Alberth> yes 20:29:52 <planetmaker> current state in trunk is... like what? 20:30:08 <planetmaker> I thought it would do that ;-) 20:30:19 <frosch123> Alberth: well, but has the player any influece on the amount of industries on the map? 20:30:52 <Alberth> trunk does something similar, but it ignores the current state of the map, and previous build attempts 20:30:55 <frosch123> the way i understand you patch, it does not matter at all what the player does. it will always head for the same number of industries 20:31:06 <andythenorth> that is desired behaviour :) 20:31:07 <Alberth> frosch123: true 20:31:32 * frosch123 does not like that behaviour :p the game is about playing after all 20:31:44 <Alberth> the player can build more industries :p 20:31:57 <Alberth> so what would you like to have? 20:32:30 <frosch123> limit changes of industry count by some % per year, so there is no mass decrease/increase 20:32:48 <planetmaker> that sounds sane 20:33:02 <frosch123> if a lot of industries close down, the total amount shall also decrease 20:33:13 <frosch123> if hardly industries close down, the total amount shall grow 20:33:52 <Alberth> ie keep some sort-of fixed number of unserviced industries around 20:34:31 <planetmaker> probably a good measure for the build attempts would be the selected "industry density" for the map. or maybe the difference between industries present and the density setting 20:34:43 <Alberth> so the player always has a choice to connect to more industries 20:34:59 <planetmaker> with a constant offset to always create some 20:35:32 * planetmaker ponders whether it'd make sense and would be attractive to players to setup a server with that patch 20:36:05 <planetmaker> seeing that there are actually binaries already around for nearly everyone 20:36:14 <Alberth> it sounds like an interesting idea, I need to think about the details though 20:38:39 <andythenorth> what are the goals wrt to industry? 20:39:13 <andythenorth> 1. make sure newly available types get built quickly 20:39:15 <andythenorth> 2. ?? 20:39:37 <Alberth> having enough free ones around to connect to 20:39:44 <Ammler> planetmaker: I wonder, if you would attract someone, since 1.0 nobody likes to play nightly or patched server anymore 20:40:05 <planetmaker> that's what I'd worry about, too :-( 20:40:52 <Ammler> stable is just too much fun already :'-( 20:40:55 <andythenorth> Alberth: free meaning unserviced? 20:41:17 <Alberth> for single player, probably 20:41:45 <Alberth> hmm, industry chains are also a factor, not sure about how that fits in the goals 20:43:02 <Alberth> on the other hand, you can also make life difficult ('hard' playing style) for the user, eg switch from coal to eg nuclear or so in a short time 20:43:11 <andythenorth> should the game be trying to provide unserviced industry? I'd never thought of that as a goal 20:43:28 <andythenorth> players need something to spend money on - they can build their own industry 20:43:29 <planetmaker> it should. some 20:43:35 * andythenorth only plays single player 20:43:42 <andythenorth> I never manage to connect all industry 20:43:43 <frosch123> night 20:43:46 <andythenorth> bye 20:43:47 <planetmaker> even in SP it's a nice thing if the game keeps going 20:43:47 *** frosch123 has quit IRC 20:43:49 <Alberth> from a player, you want industries to connect, right? 20:43:50 <planetmaker> good night... 20:44:06 <planetmaker> to me both of the goals sound quite nice and desirable. Yes 20:44:11 <Alberth> no use trying that with frosch :) 20:44:17 <planetmaker> :-) 20:44:20 <planetmaker> It's a race 20:44:25 <andythenorth> I have no problem with the second goal, I'd just never thought of it :) 20:44:45 <planetmaker> andythenorth: we always build dozens of industries once our networks are somewhat established. 20:44:57 <planetmaker> As we can connect and service industries MUCH faster than they appear 20:45:00 <andythenorth> I always fund my own once I have enough money 20:45:03 <planetmaker> at least sometimes 20:45:17 <planetmaker> funding my own is boring - except for secondaries 20:45:20 <Alberth> I never fund industries 20:45:27 <planetmaker> primaries I usually set to prospecting when I need more 20:45:32 <andythenorth> same 20:45:46 <Alberth> perhaps that's why I quit playing around the '90s :) 20:45:56 <planetmaker> but if they were there just the same... even better :-) 20:46:09 <planetmaker> Alberth: that = no industries around anymore? ;-) 20:46:33 <andythenorth> any other goals? 20:46:40 * planetmaker just reads also the NML activity... :-) 20:46:46 <planetmaker> Nice one, too! 20:46:48 <Alberth> not many and/or interesting industries 20:46:58 <andythenorth> 3. stop insanity of different amounts of some industry types, depending on date 20:47:27 <Alberth> now rephrase from a player point of view :) 20:47:47 <planetmaker> andythenorth: Alberth maybe the probability could be interpreted as a probability of all industries defined within a set 20:48:03 <andythenorth> it is isn't it? 20:48:17 * andythenorth ponders how to rephrase 20:48:26 <planetmaker> so... if I have like 20 industries defined, each with relative probability one, but 10 not (yet) available, there'd be a 50% chance that no industry will get funded by the game anyway 20:48:32 <planetmaker> that'd solve the relative funding issue 20:48:50 <planetmaker> and the relative industry amoutn issue when creating things at different times 20:48:51 <Alberth> yep, that was one of the conclusions 20:48:55 <planetmaker> ok :-) 20:49:10 <Alberth> it would be a nice experiment to see how that works 20:49:29 <planetmaker> yep, it'd need testing indeed 20:49:37 <Alberth> except for the default industries it hardly makes a difference, as only oil rigs are available later 20:50:23 <Alberth> perhaps the suggestion of frosch could be used in some way 20:50:29 <andythenorth> I can only re-express (3) in terms of FIRS :P 20:51:20 <Alberth> a player wants a good balance between the various industries in each chain 20:51:28 <andythenorth> 3. players who start a FIRS game in 1830 will have a lot of farms to deal with. Arguably, the map is spammed with farms. And towns are spammed with breweries and bakeries. Players who start in 1960 will complain that there are not enough farms. 20:51:37 <planetmaker> which suggestion exactly do you mean? 20:52:28 <planetmaker> the number decrease / increase? 20:52:28 <Alberth> have some unserviced industries always (but less than the total number of industries you get now at the start) 20:52:34 <planetmaker> oh 20:54:04 <Alberth> despite the interesting discussion, it is actually time to leave for me 20:54:07 <andythenorth> me too 20:54:13 <Alberth> good night, see you in a couple of days 20:54:21 <andythenorth> bye Alberth 20:54:25 <planetmaker> good night Alberth 20:54:34 <planetmaker> and enjoy whatever you do :-) 20:54:44 <Alberth> sleep and work, mostly 20:54:54 <planetmaker> :-) 20:55:07 <planetmaker> same same 20:58:42 <planetmaker> http://bundles.openttdcoop.org/download.php?file=swedishrails/nightlies/LATEST/log/REBUILD/r156/log/swedishrails-r156-devzone.err.log <-- Ammler I don't see why or where SE rails failed to build and why I got an error report 20:58:56 <planetmaker> and also: the CF shouldn't report errors on missing NFO for NML projects 20:59:56 *** Alberth has left #openttdcoop.devzone 21:00:14 <Ammler> yeah, the toubles today are caused because I enabled the stats script again 21:00:43 <planetmaker> ah... so all those e-mails are invalid :-) Uff... lucky me 21:00:57 <Ammler> I deleted most tickets 21:01:26 <planetmaker> yeah, saw none for SE rails now. But I looked through my e-mail. Which of course wasn't deleted ;-) 21:01:32 <Ammler> I wonder, you found a working one, please just close/delete it 21:02:16 <planetmaker> I just started looking. First e-mail, then test build locally then bundles dir on server... and didn't see that there. So I wondered whether I missed something 21:02:48 <planetmaker> as I also didn't get an e-mail that the issues assigned to me were closed ;-) 21:03:06 <planetmaker> I assumed they were valid w/o checking for them before starting to look 21:03:17 <Ammler> I can't close tickets I am not member 21:03:25 <Ammler> but I can delete as admin :-) 21:03:29 <planetmaker> :-D 21:04:43 <Ammler> and as the tickets are invalid, I felt legal to delete those :-P 21:04:57 <planetmaker> yes, sure :-) 21:05:10 <planetmaker> I asked before I looked at the issues in redmine. Or tried to 21:05:41 <planetmaker> and... using custom_tags.txt in a way you try for the makefiles looks interesting 21:07:16 <Ammler> well, it would also solve the md5 issue 21:08:06 <planetmaker> yes, could be used 21:08:50 <planetmaker> which is the thing which is really interesting about it :-) 21:09:04 <Ammler> I guess, redefine IFS doesn't work 21:13:17 <Ammler> hmm, something else 21:16:16 <Ammler> for docs, i need to define the target yet? 21:22:55 <Brot6> opengfx-clone: compile of r536 failed - http://bundles.openttdcoop.org/opengfx-clone/nightlies/ERROR/r536 21:24:13 <thgergo> Hello 21:24:15 <thgergo> Do you mind if I add some commits to TBRS soon?:) 21:25:49 <planetmaker> I don't. Why would one? It's yours ;-) 21:26:02 <planetmaker> Ammler: which target? 21:26:27 <planetmaker> the Makefiles need to define DOC_FILES = readme.txt changelog.txt license.txt 21:27:00 <planetmaker> and then docs itself defines %.txt: %.ptxt how to get from ptxt to txt (if applicable) 21:28:30 * Rubidium ponders making a remark that might be misinterpreted due to a single word having multiple meanings 21:29:14 * SmatZ can't think of such a remark 21:29:49 <Rubidium> SmatZ: I can: "I would mind" 21:30:26 <SmatZ> :) 21:30:38 <Rubidium> and then *not* the "dislike" meaning of mind, but the "to become aware of" meaning 21:33:03 <Ammler> planetmaker: I meant, if you like to build the docs without installing 21:34:02 <Ammler> this is IMO a process for building, not installing, as it can be made without root 21:35:34 <SmatZ> Rubidium: I don't know that many meanings of that word 21:43:17 <planetmaker> hehe. Mind and mind... 21:43:47 <Ammler> and we still keep that "nightly" in the filename? 21:43:56 <planetmaker> in the filename? 21:44:00 <planetmaker> in the tar 21:44:18 <planetmaker> or the zip 21:46:03 <planetmaker> Rubidium: you mean like "I mind" - but in the non-negative way, opposed to how it's usually used? 21:46:58 <planetmaker> Ammler: make all should according to the makefile build the binary. And not the documentation 21:47:03 <planetmaker> +manual 21:47:36 <Ammler> readme is not documentation or manual 21:47:50 <Ammler> readme is just readme 21:47:57 <Ammler> and doesn't need root 21:48:17 <Ammler> I don't see why you build it on install 21:48:22 <Ammler> butg not on all 21:48:23 <Rubidium> planetmaker: yes, like "mind the gap" vs "would you mind not doing that?" 21:49:13 * Rubidium still wonders the use of putting changelog and license through a preprocessor 21:49:13 <Ammler> install shouldn't build something 21:49:39 <planetmaker> Ammler: an install needs to depend upon the things it wants to install. Don't you agree? 21:49:51 <Ammler> yes, I disagree 21:49:54 <planetmaker> Rubidium: no use really 21:50:05 <SmatZ> "make install" in gcc also build some precompiled headers and other stuff :p 21:50:14 <Ammler> because make install is run as root, it should not build something 21:50:21 <planetmaker> Maybe for changelog, if you want to put some version or name tag on top of the changelog 21:50:25 <Rubidium> is anyone here keeping the changelog up-to-date until the actual release? Likely no, so why possibly put a trunk revision in it (not that it happens) 21:50:54 <planetmaker> Rubidium: there's a simple solution: rename changelog.ptxt to changelog.txt and it's not pre-processed 21:51:07 <Ammler> SmatZ: those things might need root? 21:51:30 <Rubidium> and for the license it's even weirder. Modifying it makes it harder for downstream to check whether it's modified or not 21:51:39 <planetmaker> same there 21:52:12 <SmatZ> Ammler: maybe 21:52:24 <planetmaker> might actually indeed be a good thing to not pre-process them 21:52:26 <SmatZ> it's sure for a reason 21:52:35 <Rubidium> I'd even argue that an automatic version in the readme is someone superfluous 21:52:44 <Ammler> yes, but opengfx has no reason to build the docs as root 21:52:50 <Rubidium> s/someone/something/ 21:53:01 <planetmaker> Ammler: then don't. Build them as 'make docs' 21:53:13 <Ammler> planetmaker: that isn't common 21:53:23 <Ammler> usually you run make 21:53:26 <Rubidium> the readme should be reviewed upon release anyway, so forcing you do look at it by updating the version (and release date) can be considered a good thing 21:53:28 <Ammler> and then make install 21:54:07 <planetmaker> Rubidium: running the readme through that is not the worst IMHO. It allows to put the revision and md5 into it. 21:54:22 <thgergo> svn doesnt wand let me authorizate me:( 21:54:43 <Ammler> thgergo: isn't your project moved to hg already? 21:54:56 <thgergo> I dont know whats changed 21:55:12 <thgergo> I wast here recently 21:55:55 <Ammler> we use the svn mostly for reading only anymore 21:56:04 <Ammler> if someone does continue, we convert to hg 21:56:56 <Ammler> but your project is indeed linked to svn, still 21:57:14 <Ammler> you really like to continue there or shall I move it? 21:57:28 <thgergo> you can I havent touched anything yet 21:57:51 <Ammler> or you like to start with nml :-P 21:58:49 <Rubidium> I'm not sure whether that's capable of doing the bridge stuff already 21:59:03 <thgergo> :D well as far as I renember it doesnt 21:59:52 <Ammler> http://hg.openttdcoop.org/total_bridges 22:00:12 <Brot6> OpenGFX - Revision 536:94e94ef91f67: Change: No need to process or modify license and changelog d... (planetmaker) @ http://dev.openttdcoop.org/projects/opengfx/repository/revisions/94e94ef91f67 22:00:31 <Ammler> thgergo: you know hg? 22:00:38 <thgergo> not yet... 22:00:59 <thgergo> its like an extension to svn? 22:01:11 <planetmaker> it's like another hg 22:01:16 <planetmaker> *another svn 22:02:56 <Ammler> http://dev.openttdcoop.org/projects/home/wiki/Mercurial <-- quick overview 22:03:11 <Ammler> at the bottom are also some little help pages 22:03:37 <Ammler> but basically it is svn ci = hg ci && hg push 22:03:39 <planetmaker> oh, nice page there, Ammler :-) 22:03:48 <Ammler> svn co = hg clone 22:03:55 <Ammler> svn up = hg pull -i 22:04:01 <Ammler> hg pull -u 22:04:06 <Ammler> not -i 22:04:58 <planetmaker> good night 22:05:13 <Ammler> thgergo: you use gnome? 22:05:17 <SmatZ> good night, planetmaker 22:05:19 <thgergo> yes 22:05:34 <Ammler> tortoisehg might be something 22:05:36 <thgergo> Im searching a good client now, rather than using the terminal 22:06:11 <Ammler> I use hgtk, that is mini tortoise 22:06:33 <thgergo> i will try that 22:06:52 <thgergo> also the commit password, is same as from the login? 22:07:21 <Ammler> yep, devzone login 22:07:42 <Ammler> but there is no commit pw, that is push :-) 22:07:56 <Ammler> you commit locally and then push 22:13:38 <thgergo> tortoisesvn doesnt want to inject the scripts menu into nautilus, as I saw in some screenshots... 22:13:49 <thgergo> ill try some other 22:14:07 <Rubidium> isn't nautilus something unixy/linuxy? 22:15:08 <thgergo> yes, I have aready restarted that 22:15:14 <thgergo> no changes 22:15:45 <Rubidium> I really doubt that an application built to tie into Microsoft's Explorer ties into Nautilus 22:16:10 <thgergo> I have installed via apt-get 22:16:30 <thgergo> it should be a bunchs of scripts 22:16:50 <Rubidium> talking about tortoisehg then, aren't you? 22:16:59 <thgergo> yes 22:17:02 <Rubidium> installed the tortoisehg-nautilus extension? 22:17:07 <thgergo> yes 22:17:16 <thgergo> but it doesnt work 22:17:17 <Rubidium> then file a nice bug report :) 22:17:27 <Ammler> thgergo: hg not svn 22:17:35 <thgergo> tortoisehg 22:17:52 <thgergo> I meant that sorry... 22:18:12 <Ammler> well, I have no idea, don't use gnome 22:18:26 <Ammler> I am quite fine with the console and hgtk 22:18:31 *** Seberoth has quit IRC 22:19:33 <thgergo> ok its works now 22:19:34 <Ammler> and tortoisehg has no similar feature for KDE 22:19:39 <thgergo> simply bad pactage 22:30:15 *** Seberoth has joined #openttdcoop.devzone 22:34:20 *** ODM has quit IRC 22:37:27 *** GT has left #openttdcoop.devzone 22:47:03 <Brot6> opengfx-clone: update from to 0.3.0 done - http://bundles.openttdcoop.org/opengfx-clone/releases/0.3.0 22:47:17 <Brot6> OpenGFX - Revision 537:b4ea6c61edaf: Feature: build from source bundle and make rpm (Ammler) @ http://dev.openttdcoop.org/projects/opengfx/repository/revisions/b4ea6c61edaf 22:48:03 <Ammler> mäh 22:48:46 <Brot6> OpenGFX - Bug #1489 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/1489 22:51:54 <Brot6> opengfx: compile of r537 still failed (#1489) - http://bundles.openttdcoop.org/opengfx/nightlies/ERROR/r537 22:59:53 <thgergo> Ammler: How can i set the login/pass in tortoisehg? Is there an "elegant" solution for that? I havent even notice about that in its manual:S 23:00:27 <Ammler> I assume, it does save the url once you have used it 23:00:33 <Ammler> else add it to .hg/hgrc 23:00:56 <Ammler> (it is part of the url) 23:01:14 <Ammler> https://<user>:<pw>@push... 23:01:45 <Ammler> it might be possible to save login data to the ~/hgrc 23:02:34 * SmatZ prefers typing the password everytime he commits. It has saved him at least two accidental commits 23:06:28 <Yexo> with hg that isn't a problem, because the accidental commit can be undone before you push your changes 23:10:25 <Brot6> NewGRF Meta Language - Revision 767:e91b719fdcae: Feature: allow adding units to switch-block ranges (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/e91b719fdcae 23:10:25 <Brot6> NewGRF Meta Language - Revision 768:4ab7b131bddd: Add: vehicle variables max_speed and current_speed (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/4ab7b131bddd 23:11:13 <Brot6> OpenGFX - Revision 538:1f9d13e4ba77: Fix rPREV: logging path were wrong and not incremental (Ammler) @ http://dev.openttdcoop.org/projects/opengfx/repository/revisions/1f9d13e4ba77 23:13:19 <Yexo> http://pastebin.ca/1939173 <- example of the new syntax 23:15:56 <Rubidium> is it already implemented? 23:16:02 <Yexo> yes 23:16:03 <Brot6> opengfx: update from r535 to r538 done - http://bundles.openttdcoop.org/opengfx/nightlies/r538 23:16:07 <Rubidium> in any case, I've got a good testcase for it :) 23:16:54 <Ammler> hmm, why is the rpm 500kb smaller? 23:17:17 <Ammler> does it have such better compression than zip 23:17:18 <Rubidium> it's a meta-testcase though: there's a moment where N km/h and N+1 km/h get matched to the same km-ish/h, now what happens if I use N: return 10; N+1: return 11; N+2; return 12; ? 23:17:36 <Rubidium> Ammler: if it uses xz or bz2, there that's quite likely 23:17:47 <Yexo> the N+1 case will never be triggered 23:18:05 <Ammler> I do an unrpm to be sure :-) 23:18:11 <Rubidium> then that should trigger a warning I'd say 23:18:45 <Yexo> imo using unit conversions without a range (ie 10..20 km/h) is quite stupid 23:18:53 <Yexo> maybe that in itself should trigger a warning already 23:19:32 <Rubidium> Ammler: zip: 7.9, tar.gz: 7.2, tar.bz2: 5.5, tar.xz: 4.8 23:20:20 <Rubidium> (r20789 source tarball, last repacked with xz and default settings) 23:21:10 <Ammler> yes, everything in 23:21:27 <Rubidium> tar.xz with -9: 4.7 MiB 23:21:40 <Rubidium> !calc 4.7/7.9 23:21:44 <Rubidium> @calc 4.7/7.9 23:21:44 <Webster> Rubidium: 0.594936708861 23:21:54 <Rubidium> 40% better than zip :) 23:23:14 <Ammler> yeah, seems so, the rpm of a year ago are still 3mb 23:23:30 <Rubidium> on OpenTTD binary packages the difference is quite a bit smaller though; 4.3, 4.0, 4.0, 3.3 23:23:31 <Ammler> i mean the same rpm of a year old distro 23:24:06 <Rubidium> if only there'd be a stable release of xz, then I'd consider changing .bz2 -> .xz 23:24:54 <Rubidium> and an afternoon of CPU load for the server to recompress the old .bz2 nightly files to .xz 23:25:07 <Ammler> :-) 23:36:34 <thgergo> should I use this? ssh://ottdc@hg.openttdcoop.org/hg-repos/<project> [<alias>] 23:38:56 <Ammler> no 23:39:00 <Ammler> https 23:39:11 <Ammler> where do you have that from? 23:40:10 <Ammler> http://dev.openttdcoop.org/projects/home/wiki/Mercurial 23:41:28 <thgergo> from that link 23:53:44 <thgergo> hg clone https://user:password@push.openttdcoop.org/project gives only abort: HTTP Error 404: Not Found even in a terminal:S 23:54:32 <thgergo> I getting fed up with hg:( im gonna sleep soon 23:55:25 <Brot6> NewGRF Meta Language - Revision 769:41487479015e: Change: print a warning if a switch-range overl... (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/41487479015e 23:58:01 *** KenjiE20 has quit IRC