Log for #openttdcoop.devzone on 12th September 2010:
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. 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) @
13:26:02  <Brot6> 32bpp-ez-patches - Feature #1468: Profile and optimize CC blending algorithm (GeekToo) @
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: something like this prevents it from being optimised away
13:55:19  <Webster> Title: - free nopaste script and service (at
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, 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) @
15:52:05  <Brot6> NewGRF Meta Language - Revision 758:0109924fd504: Add: Vehicle variables 0xBA / 0xBC (cargo_capac... (Hirundo) @
15:52:05  <Brot6> NewGRF Meta Language - Revision 759:460530251feb: Codechange: Generalize the sign-extension code ... (Hirundo) @
15:52:07  <Brot6> NewGRF Meta Language - Revision 756:e1f94f674741: Add: Vehicle variable 0x5F (waiting_triggers / ... (Hirundo) @
15:52:11  <Brot6> NewGRF Meta Language - Revision 760:e7d2c216acad: Add: A few vehicle_is_xxx vehicle variables. (Hirundo) @
15:52:15  <Brot6> NewGRF Meta Language - Revision 761:80d8d5e70812: Add: Two breakdown-related vehicle variables (r... (Hirundo) @
15:57:02  <Brot6> NewGRF Meta Language - Bug #1469 (New): documentation about 'graphics' is wrong (Hirundo) @
15:58:20  <Brot6> OpenGFX - Bug #1470 (New): makefile issues (Ammler) @
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) @
16:08:07  <Brot6> NewGRF Meta Language - Revision 762:e76ae4ee50de: Codechange: Move check of 255 pieces limit, exp... (Alberth) @
16:08:07  <Brot6> NewGRF Meta Language - Revision 765:342d89caaeca: Feature: Implement creation of multiple ActionF... (Alberth) @
16:08:09  <Brot6> NewGRF Meta Language - Revision 764:41be407e8a2e: Feature: Drop names with 0 probability. (Alberth) @
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> compile of r486 failed -
16:22:13  <Brot6> nml: update from r751 to r765 done -
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) @
16:24:23  <Brot6> 32bpp-extra - Bug #1472 (New): DevZone compile failed (compiler) @
16:24:58  <Brot6> Base Costs Mod - Bug #1473 (New): DevZone compile failed (compiler) @
16:24:58  <Brot6> Belarusian Town Names - Bug #1474 (New): DevZone compile failed (compiler) @
16:24:58  <Brot6> Comic Style Houses - Bug #1475 (New): DevZone compile failed (compiler) @
16:26:15  <Brot6> FISH - Bug #1476 (New): DevZone compile failed (compiler) @
16:26:15  <Brot6> French Town Names - Bug #1477 (New): DevZone compile failed (compiler) @
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) @
16:27:37  <Brot6> Metro Track Set - Bug #1479 (New): DevZone compile failed (compiler) @
16:27:37  <Brot6> Nutracks - Bug #1480 (New): DevZone compile failed (compiler) @
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) @
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) @
16:34:53  <Brot6> Swedish Rails - Bug #1483 (New): DevZone compile failed (compiler) @
16:34:53  <Brot6> Swiss Town Names - Bug #1484 (New): DevZone compile failed (compiler) @
16:34:53  <Brot6> TransRapid Track Set - Bug #1485 (New): DevZone compile failed (compiler) @
16:34:53  <Brot6> Total Town Replacement Set - Bug #1486 (New): DevZone compile failed (compiler) @
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) @
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) @
16:48:08  <Brot6> OpenGFX+ Airports - Revision 59:b69876cf0101: Fix #1467: we need to set build type for non nfo pr... (Ammler) @
16:48:09  <Brot6> OpenGFX+ Airports - Bug #1467 (Closed): DevZone compile failed (Ammler) @
16:48:09  <Brot6> FIRS Industry Replacement Set - Feature #1466: Consider if Machine Shop should accept MNSP (andythenorth) @
16:48:11  <Brot6> 2cc train set - Bug #1471 (New): DevZone compile failed (compiler) @
16:48:51  <Brot6> AP+ MQ - Revision 2:01a5b85148bb: Add set welcome location (Ammler) @
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) @
16:59:37  <Brot6> OpenGFX+ Airports - Revision 57:31d5d352499d: Add: nml code for small airport (yexo) @
16:59:37  <Brot6> OpenGFX+ Airports - Revision 58:784777d5ba42: Fix: remove superfluous spaces from custom_tags.txt (yexo) @
16:59:39  <Brot6> FIRS Industry Replacement Set - Revision 1359:01ad3106d0d9: Fix: Paper Mill didn't accept Clay on... (andythenorth) @
16:59:43  <Brot6> FIRS Industry Replacement Set - Feature #1462 (New): No more changes to cargo chains until econom... (andythenorth) @
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) @
16:59:49  <Brot6> FIRS Industry Replacement Set - Revision 1360:ee605b924118: Feature: Paper Mill accepts Chemicals (andythenorth) @
16:59:53  <Brot6> FIRS Industry Replacement Set - Revision 1361:9083591f3677: Feature: update industry window texts... (andythenorth) @
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) @
17:00:00  <Brot6> FIRS Industry Replacement Set - Feature #1466 (New): Consider if Machine Shop should accept MNSP (andythenorth) @
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) @
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) -
18:10:38  <Brot6> serverpatches: update from r20786 to r20789 done (4 errors) -
18:10:57  <Brot6> 32bpp-extra - Bug #1472: DevZone compile failed (GeekToo) @
18:12:33  <Brot6> 32bpp-extra - Bug #1472: DevZone compile failed (GeekToo) @
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) @
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) @
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) @
18:28:21  <frosch123> haha, no, i started 19:11 or so :)
18:28:47  <Ammler> <-- what is wrong here? (scripts/Makefile.common:82: *** commands commence before first target.  Stop.)
18:28:49  <Brot6> OpenGFX - Bug #1470: makefile issues (Ammler) @
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) @
18:57:32  <Brot6> 32bpp-ez-patches - Revision 64:d802a1bd33c3: Add: enable push build (GeekToo) @
19:05:57  <Brot6> 32bpp-ez-patches: update from  to r64 done (2 errors) -
19:08:12  <Brot6> 32bpp-ez-patches - Bug #1488 (New): DevZone compile failed (compiler) @
19:09:44  <Hirundo> Yexo: <- 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) @
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) @
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) -
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) @
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:
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 "OpenGFX - Bug #1470: makefile issues - #openttdcoop Development Zone"
20:15:21  <Brot6> FIRS Industry Replacement Set - Revision 1362:451f0f64872e: Fix: Retail Market typo (andythenorth) @
20:15:21  <Brot6> FIRS Industry Replacement Set - Revision 1363:c78033a373c7: Add: graphics files for Brick Works (andythenorth) @
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> <-- like that page, Alberth ?
20:17:35  <Ammler> Alberth: it's not
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) @
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> <-- 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 -
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>
22:00:12  <Brot6> OpenGFX - Revision 536:94e94ef91f67: Change: No need to process or modify license and changelog d... (planetmaker) @
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> <-- 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 -
22:47:17  <Brot6> OpenGFX - Revision 537:b4ea6c61edaf: Feature: build from source bundle and make rpm (Ammler) @
22:48:03  <Ammler> mäh
22:48:46  <Brot6> OpenGFX - Bug #1489 (New): DevZone compile failed (compiler) @
22:51:54  <Brot6> opengfx: compile of r537 still failed (#1489) -
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) @
23:10:25  <Brot6> NewGRF Meta Language - Revision 768:4ab7b131bddd: Add: vehicle variables max_speed and current_speed (yexo) @
23:11:13  <Brot6> OpenGFX - Revision 538:1f9d13e4ba77: Fix rPREV: logging path were wrong and not incremental (Ammler) @
23:13:19  <Yexo> <- 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 -
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://<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>
23:41:28  <thgergo> from that link
23:53:44  <thgergo> hg clone 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) @
23:58:01  *** KenjiE20 has quit IRC

Powered by YARRSTE version: svn-trunk