Log for #openttdcoop.devzone on 14th February 2015:
Times are UTC Toggle Colours
00:04:46  <DevZone> Project xussrset - Trains from Russia build #837-push: SUCCESS in 3 min 41 sec:
00:42:13  *** gelignite has quit IRC
01:01:07  *** oskari89 has quit IRC
04:34:34  *** LSky` has joined #openttdcoop.devzone
08:51:27  *** Alberth has joined #openttdcoop.devzone
10:12:14  *** oskari89 has joined #openttdcoop.devzone
10:39:12  <planetmaker> Alberth: that funky make error with ogfx-trains: was it local to you or did I mess up more thoroughly that CF failed?
10:39:24  <Alberth> moin :)
10:39:29  <Alberth> locally
10:40:03  <planetmaker> moin indeed :)
10:40:26  <Alberth> I was trying to adjust smoke stuff, but it died on building already :p
10:40:34  <planetmaker> but yeah... looks a bit like over-engineered. Though there's some version thingy which one needs to consider...
10:40:41  <planetmaker> not sure it's relevant, though, anymore
10:41:14  <Alberth> I think I managed to build a version in the end, but haven't yet tested it
10:43:05  <Alberth> (maybe I should actually change the offset first, so you can see something has changed :p )
10:43:16  <planetmaker> at least it's weired. The test -n UNIX2DOS will always succeed. Unless you explicitly define it as ""
10:44:31  <planetmaker> hm... but yeah. That avoids issuing -q when $UNIX2DOS is "" when not found
10:45:17  <Alberth> tbh I have no idea what it is supposed to do
10:46:13  <planetmaker> it's supposed to set the unix2dos_flag to -q when unix2dos is actually not ""
10:46:37  <planetmaker> does it help if you modify line 5 of your paste such that you redirect 1>&2 > /dev/null
10:46:59  <planetmaker> err... 1>&2 2>/dev/null
10:47:06  <planetmaker> I think. I always fail with this
10:48:30  <planetmaker> basically it needs to check whether $(UNIX2DOS) -q --version gives subsequently $? = 0 or $? != 0
10:48:46  <planetmaker> and the >/dev/null should ensure that there's no stray output :)
10:48:55  <planetmaker> which seems to fail for your setup
10:50:22  <planetmaker> the whole point of this magic is: it's very stupid to fail the build, if s/o hasn't unix2dos to convert the readme to the proper line endings
10:51:38  <Alberth>     bash(1) said to add it at the end :)
10:52:45  <planetmaker> so build works with that change for you?
10:53:11  <planetmaker> then that's the bug :) the missing 2>&1
10:53:43  <planetmaker> you want to add that to your patch series?
10:54:13  <Alberth> currently testing :)
10:54:58  <Alberth> sloooow :p
10:55:17  <planetmaker> :D
10:55:32  <planetmaker> current ogfx+trains includes some 32bpp
10:55:38  <Alberth> lots of 32bpp pictures, apparently
10:55:39  <planetmaker> I wonder whether the next release should contain that
10:55:54  <planetmaker> yes, it's all xotic's rendered stuff
10:56:06  <Alberth> does it looks any good?
10:56:14  <planetmaker> so-so, I think.
10:56:28  <Alberth> given the popularity of 32bpp, it might be a good choice to add it
10:56:53  <planetmaker> but my main "concern" actually is: OpenGFX+xxx is not exactly something which lends its name to 32bpp. It then should rather be zbase+trains. Or so
10:56:53  <Alberth> even at zbase quality :)
10:57:22  <Alberth> hmm
10:57:22  <planetmaker> thus I wonder whether it's proper to fork it. Or not worth the trouble and to argue "if you want 8bpp, set your blitter"
10:57:59  <Alberth> eventually, all newgrfs will be 32bpp is my guess
10:58:08  <Alberth> unless openttd dies before that
10:58:25  <planetmaker> hm, maybe. Not sure
10:58:38  <planetmaker> but yeah, even pixel pushing in 32bpp is easier than with 8bpp
10:58:39  <Alberth> and it's still an enhancement wrt the original base set
10:59:24  <Alberth> pineapple  also doesn't shout 32bpp in its name
10:59:45  <planetmaker> no, it doesn't. But of course it's something entirely different :)
11:00:01  <planetmaker> But ok, you made a valid argument for just ignoring the 8bpp stuck to ogfx name
11:00:12  <planetmaker> as I'm mostly undecided, yes, I don't mind then
11:00:23  <Alberth> add 32bpp to ogfx :p
11:00:38  <planetmaker> though I wonder... I think it's not entirely 32bpp, this newgrf. That might look a bit awkward
11:00:42  <planetmaker> hm hm :)
11:01:30  <Alberth> yeah, that should be clearly mentioned to avoid nasty surprises when people download it
11:01:49  <Alberth> is there some era that is covered, or a climate?
11:02:00  <planetmaker> I really don't know
11:03:07  <Alberth>   trick works here, except I did it in reverse (less work :) )
11:04:02  <planetmaker> :) wonderful
11:04:13  <Alberth> what about the other  /dev/null  redirections?
11:05:57  <Alberth> mountains were all there last week?
11:09:04  <planetmaker> the other /dev/null redirections probably need the same fix
11:09:28  <planetmaker> the mountains last week were very snowy and sunny. walking on them very exhausting :)
11:10:43  <Alberth> as it should be :)     and looking splendid no doubt :)
11:11:42  <planetmaker> oh yes, it did :) When I strayed off the path for a few photos, I was up to my knees sunken in snow :)
11:12:10  <Alberth> quicksnow :p
11:13:02  <planetmaker> not so quick. But just much :) (or what accounts to much for a person who is happy to see 1cm of snow at home in winter) :D
11:13:28  <Alberth> I have email contact with a 12 year old girl doing python coding, through her teacher. I's amazing what kids can write these days :)
11:14:04  <Alberth> django, ajax, guis :)
11:14:05  <planetmaker> he :) yeah, those who are eager to learn and quick with their mind... they can do an awesome lot at early age
11:14:29  <planetmaker> important is the 'eager and interested'
11:14:38  <Alberth> yep :)
11:15:29  <Alberth> and then you have an entire Internet filled with interesting things :)
11:18:57  <planetmaker> very much so :)
11:19:30  <planetmaker> do you meanwhile actually know as to what happens with your working group?
11:19:55  *** frosch123 has joined #openttdcoop.devzone
11:20:00  <planetmaker> quak
11:20:28  <Alberth> hi hi
11:21:05  <Alberth> nope, but the first evaluation of the financial state is in March, so I expect something to happen
11:21:25  <planetmaker> hm, sucks, this dragging
11:21:25  <Alberth> also, it has become clear nobody at the university needs a programmer :(
11:21:30  <planetmaker> :(
11:22:19  <Alberth> yet everybody does stuff with software :p
11:24:36  <frosch123> hola
11:31:09  <frosch123> i would also recommend to split the 32bpp parts of ogfx+trains into a separate grf
11:31:20  <frosch123> it has a completely different art-style
11:31:21  <Rubidium> good day y'all ;)
11:31:48  <frosch123> the same grf should still be the same grf, otherwise we have to add a setting to disable 32bpp for specific sets :)
11:31:52  <frosch123> hello Rubidium :)
11:33:33  <Rubidium> Alberth: sounds like the typical resources issue at a university. Can't get a dedicated "programmer" on your money grant proposal, so the ones with some affinity with computers muddle about a bit to get things done
11:33:52  <planetmaker> heya Rubidium
11:34:09  <Rubidium> even then, when there is a dedicated group... it takes too long to get the quick responses you need so they're still relatively on their own
11:34:29  <Rubidium> though that also happens in the "corporate" world...
11:35:18  <planetmaker> yep
11:35:26  <planetmaker> it means to talk to eachother ;)
11:36:22  <Alberth> in this case, most of the faculty is developing and implementing numerical algorithms, highly specific stuff
11:36:55  <Alberth> obviously, I am not going to win from that, but I can make a huge difference at a higher abstraction level
11:37:00  <planetmaker> yeah... especially there, one could assume, it makes sense to have a few who really know their stuff. Like you
11:37:03  <Alberth> if only they realized that :(
11:37:08  <planetmaker> Most scientiest don't do as well
11:37:46  <Alberth> but they make the decisions
11:37:56  <Alberth> oh joy :(
11:39:19  <planetmaker> yes, I also realize, most scientists don't care about proper programming. It's mostly about the immediate gain when programming. Unlike what they do scientifically
11:39:20  <Alberth> so pondering a lot what kind of job to look for outside the university
11:39:44  <planetmaker> Even when they would ultimately gain a lot by doing it properly. And even spending a tiny amount of time initially to learn some basics and basics tools
11:39:56  <Rubidium> planetmaker: so... that's why I'm finding so many horrendous LabVIEW applications ;)
11:40:10  <planetmaker> Rubidium: sure. Avanti diletanti. Just like me :P
11:41:21  <Rubidium> Alberth: maybe ASML or so?
11:41:36  <Alberth> a colleague scientist is doing research in traffic lights, and we're wondering what they use to specify a crossing. I gamble an excel spread sheet :p
11:41:56  <Alberth> ^ a commercial company
11:42:05  <Rubidium> Alberth: is that in Amersfoort?
11:42:06  <Alberth> Rubidium: that's a good option indeed
11:42:22  <Alberth> I don't know where they are located
11:43:37  <frosch123> i participated in a federal programming contest 10 years ago. one of the task was programming a traffic light with some arbitrary finite-state-machine language
11:43:40  <Alberth> but basically, it's a matrix with conflicting traffic streams, and switching times to change between streams
11:44:21  <frosch123> the language was completely broken by design, and it forced certain buggy behaviour on whatever traffic light implementation there was, like not reacting on buttons or messing up timings
11:44:40  <frosch123> since i moved houses to this town, i experience exactly that behaviour at local traffic lights :p
11:44:46  <Alberth> :)
11:45:37  <Alberth> he researches at a higher level, optimal throughput by analyzing flows in the graph
11:46:32  <Alberth> which I find somewhat amazing that nobody has done that already
11:48:19  <Rubidium> except that "optimal" flow isn't always what they're looking for
11:48:53  <Rubidium> on the other hand, if you link multiple intersections then you can gain some knowledge for small optimisations
11:53:50  <Alberth> oh, they are looking for optimal, but 'optimal' takes different forms, and changes over time, etc
11:56:50  <Rubidium> they should apply the (Dutch) railway rules for planning crossing (3 min) and following (2 min) other trains for planning car trips. Then it would be fairly unlikely there'll be massive traffic jams or a significant reason to optimize traffic lights themselves ;)
11:56:58  <Rubidium> it would also be a lot safer
11:58:09  <Alberth> :)
11:58:47  <Alberth> and for tracks without crossings?
11:59:16  <Alberth> or is that done by signals entirely
11:59:59  <Rubidium> no, the planning tool from ProRail accounts for a certain amount of time between trains there too
12:00:32  <Rubidium> IIRC that's the 2 minutes
12:04:26  <Alberth> planetmaker:   looks good to you?
12:05:47  <planetmaker> Alberth: I'm not sure about the 2> &1 in the instances where the command is actually executed for effect, thus the last 3 hunks
12:06:05  <planetmaker> because when those fail, it's a real failure
12:06:44  <planetmaker> (while I want a rather silent execution when it works as expected)
12:06:45  <Alberth> good point
12:09:06  <frosch123> isn't ProRail belgian?
12:11:11  <Rubidium> frosch123: not that I'm aware of. As far as I am aware ProRail does the rail infrastructure in the Netherlands and InfraBel in Belgium
12:12:52  <frosch123> ok, then, luckily i have no direct customer contact there :)
12:14:58  <frosch123> though iirc some other dutch customers agreed that my former dutch boss' boss was rather belgian
12:19:07  <DevZone> Project OpenGFX+ Trains build #48-push: SUCCESS in 9 min 55 sec:
12:32:23  *** Supercheese is now known as Guest5363
12:32:26  *** Supercheese has joined #openttdcoop.devzone
12:36:43  *** Guest5363 has quit IRC
12:47:48  <DevZone> Project 2ccts build #391-push: SUCCESS in 1 min 27 sec:
12:58:34  <Alberth> planetmaker: 32bpp sprites are very dark
13:00:20  <Alberth> for toyland, at least
13:01:06  <frosch123> iirc the sizes of the 32bpp/8bpp sprites were even different
13:01:32  <frosch123> like: different vehicle lengths
13:03:43  <Alberth> looks like it, offset is -2/-3 with 32bpp
13:04:28  <Alberth> but it's quite consistent in all orientations
13:38:14  <Alberth>
13:39:33  <frosch123> looks like the emission height is too low
13:40:32  <Alberth> yes, and the \ at the bottom left looks off-center
13:41:13  <frosch123> luckily you can alter the emission height in 1.5 :)
13:41:24  <planetmaker> :)
13:41:34  <DevZone> Project 2ccts build #392-push: SUCCESS in 1 min 26 sec:
13:42:18  <Alberth> how to do this in general?
13:42:33  <Alberth> smoke should be right for both engines at the same time?
13:42:45  <Alberth> or can you position for each case?
13:43:14  <Alberth> ie \ 32bpp, and 8bpp  are linked wrt smoke?
13:43:15  <planetmaker> sorry, I haven't gotten the hold of the discussion yet entirely. what's the problem? Isn't it just for each engine that it can be adjusted?
13:43:21  <planetmaker> oh, yes, that they are
13:43:28  <planetmaker> it's the same thing. Then fix it for 8bpp
13:43:49  <planetmaker> after all it's supposed to be the representation of the same thing, not different vehicles
13:44:06  <planetmaker> thus sizes *should* be the same. When they aren't, it's more a reason to fork and release separately
13:44:33  <frosch123> Alberth: that's why i think ogfx+trains should be split in two projects
13:44:37  <Alberth> so you make it fit with one of both cases, and then move the engine in the other case?
13:44:39  <frosch123> the 32bpp sprites are completely different
13:44:43  <planetmaker> but we (I :P) should do somewhen. It's worth it, that people can at least use it. though I'll not be sad, if someone [TM] wants to do the coding
13:45:00  <frosch123> one grf should not feature two entirely different sets of graphics :)
13:45:05  <planetmaker> yep
13:45:46  <planetmaker> Alberth: do you want to cater for the 8bpp or 32bpp?
13:45:47  <Alberth> euhm, you consider the 32bpp and 8bpp train as really different trains?
13:45:56  <frosch123> basically  put default branch into a new project, and then strip ogfx+trains starting at the old 0.4 release
13:46:05  <DevZone> Project 2ccts build #393-push: SUCCESS in 1 min 27 sec:
13:46:16  <frosch123> Alberth: in the ogfx+trains case i think they are very different
13:46:45  <frosch123> they are so different that as i user i would like to choose between them, instead of being forced one depending on my blitter setting
13:47:00  <frosch123> zbase is also not a part of opengfx :)
13:47:23  <frosch123> in the nuts case it may work, since the same guy is drawing them
13:47:58  <frosch123> but even V considers making a separate 32bpp train set due to the issues with 32bpp nuts
13:49:17  <Alberth> ok, the 32bpp is definitely longer, so I can see they are different
13:49:37  <Alberth> planetmaker: 8bpp in that case
13:50:16  <Alberth> 32bpp looks too dark for toyland
13:50:32  <Alberth> not to mention several wagons look like the same
13:51:07  <planetmaker> yeah, that's one of the shortcomings of the 32bpp in this set I remember.
13:51:22  <frosch123> iirc ogfx+trains uses recolour tricks for wagon variety, but that stuff just does not work nicely with 32bpp
13:51:23  <planetmaker> gotta go shopping now, though. Do what you think is best. It will be best :)
13:51:46  <frosch123> so yeah, more reasons for making separate 8bpp / 32bpp sets :)
13:51:59  <Alberth> haha :)   I just claimed I don't know what I am doing at the forums :p
13:52:18  <frosch123> isn't that in your signature?
13:52:25  <Alberth> also
13:52:49  <Alberth> so raise smoke, align it mostly, and then fiddle with engine coordinates?
13:53:25  <frosch123> you can try :)
13:53:31  <Alberth> ignoring 32bpp
13:54:02  <Alberth> well, as someone said, that's best :)
13:54:07  <Alberth> thanks :)
13:54:18  <frosch123> for raising the smoke, you need to replace visual_effect_and_powered with effect_spawn_model_and_powered
13:54:34  <frosch123> and create_effect
13:56:57  <Alberth> hmm, where did andy hide that fishy code? :)
13:56:57  <DevZone> Project 2ccts build #394-push: SUCCESS in 1 min 23 sec:
13:57:37  <frosch123> i guess better run the python and look at the generated nml :)
13:58:15  <Alberth> yep :)
13:58:19  <DevZone> Project 2ccts build #395-releases: SUCCESS in 1 min 22 sec:
14:00:18  <Alberth> ah, it's   'effect_spawn_model' with ships
14:08:33  <Alberth> :O    | operator in the table hides some text (train properties 'effect_spawn_model_and_powered' row)
14:10:06  <frosch123> :p
14:10:28  <frosch123> iirc ottd wiki has some {{|}} template to fix such magic
14:10:53  <frosch123>! <- yeah, newgrfspecs has it as well
14:11:15  <frosch123> {{!}}, not {{|}}
14:15:40  <Alberth> both fail, but  <nowiki>|</nowiki>  works
14:40:32  *** gelignite has joined #openttdcoop.devzone
15:24:17  <Alberth> ugh, cargo graphics are broken :(
16:38:26  *** andythenorth has joined #openttdcoop.devzone
16:40:18  <DevZone> Project xussrset - Trains from Russia build #838-push: SUCCESS in 3 min 50 sec:
16:42:51  *** frosch123 has quit IRC
16:45:31  <DevZone> Project Iron Horse build #1227-push: SUCCESS in 4 min 23 sec:
16:51:30  <DevZone> Project xussrset - Trains from Russia build #839-push: SUCCESS in 3 min 49 sec:
16:51:37  <DevZone> Project Busy Bee GameScript build #11-push: SUCCESS in 7.3 sec:
16:51:41  <DevZone> Project Iron Horse build #1228-push: SUCCESS in 4 min 31 sec:
16:51:57  <DevZone> Project Fake Subways build #46-push: SUCCESS in 20 sec:
16:53:04  <DevZone> Project 2ccts build #396-push: SUCCESS in 1 min 23 sec:
16:53:08  *** frosch123 has joined #openttdcoop.devzone
17:22:54  <DevZone> Project Iron Horse build #1229-push: SUCCESS in 4 min 19 sec:
17:27:55  <DevZone> Project Iron Horse build #1230-push: SUCCESS in 4 min 18 sec:
17:34:20  <DevZone> Project xussrset - Trains from Russia build #840-push: SUCCESS in 3 min 36 sec:
18:06:44  <DevZone> Project Iron Horse build #1231-push: SUCCESS in 4 min 18 sec:
20:12:37  *** oskari892 has joined #openttdcoop.devzone
20:17:31  *** oskari89 has quit IRC
20:47:27  <DevZone> Project World Airliner Set build #903-push: SUCCESS in 3 min 0 sec:
21:06:22  *** Alberth has left #openttdcoop.devzone
21:22:35  *** andythenorth has left #openttdcoop.devzone
22:28:26  *** frosch123 has quit IRC
23:42:09  <DevZone> Project xussrset - Trains from Russia build #841-push: SUCCESS in 3 min 47 sec:
23:52:15  *** yorick has quit IRC

Powered by YARRSTE version: svn-trunk