Times are UTC Toggle Colours
00:04:46 <DevZone> Project xussrset - Trains from Russia build #837-push: SUCCESS in 3 min 41 sec: https://jenkins.openttdcoop.org/job/xussrset/837/ 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> https://paste.openttdcoop.org/pmrtvpehn 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> https://paste.openttdcoop.org/padcfwqxa 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: https://paste.openttdcoop.org/pa5zphd3b 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: https://jenkins.openttdcoop.org/job/ogfx-trains/48/ 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: https://jenkins.openttdcoop.org/job/2ccts/391/ 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> http://devs.openttd.org/~alberth/ploddy_smoke_8bpp.png http://devs.openttd.org/~alberth/ploddy_smoke_32bpp.png 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: https://jenkins.openttdcoop.org/job/2ccts/392/ 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: https://jenkins.openttdcoop.org/job/2ccts/393/ 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: https://jenkins.openttdcoop.org/job/2ccts/394/ 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: https://jenkins.openttdcoop.org/job/2ccts/395/ 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> https://newgrf-specs.tt-wiki.net/wiki/Template:! <- 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: https://jenkins.openttdcoop.org/job/xussrset/838/ 16:42:51 *** frosch123 has quit IRC 16:45:31 <DevZone> Project Iron Horse build #1227-push: SUCCESS in 4 min 23 sec: https://jenkins.openttdcoop.org/job/iron-horse/1227/ 16:51:30 <DevZone> Project xussrset - Trains from Russia build #839-push: SUCCESS in 3 min 49 sec: https://jenkins.openttdcoop.org/job/xussrset/839/ 16:51:37 <DevZone> Project Busy Bee GameScript build #11-push: SUCCESS in 7.3 sec: https://jenkins.openttdcoop.org/job/busy-bee-gs/11/ 16:51:41 <DevZone> Project Iron Horse build #1228-push: SUCCESS in 4 min 31 sec: https://jenkins.openttdcoop.org/job/iron-horse/1228/ 16:51:57 <DevZone> Project Fake Subways build #46-push: SUCCESS in 20 sec: https://jenkins.openttdcoop.org/job/fake-subways/46/ 16:53:04 <DevZone> Project 2ccts build #396-push: SUCCESS in 1 min 23 sec: https://jenkins.openttdcoop.org/job/2ccts/396/ 16:53:08 *** frosch123 has joined #openttdcoop.devzone 17:22:54 <DevZone> Project Iron Horse build #1229-push: SUCCESS in 4 min 19 sec: https://jenkins.openttdcoop.org/job/iron-horse/1229/ 17:27:55 <DevZone> Project Iron Horse build #1230-push: SUCCESS in 4 min 18 sec: https://jenkins.openttdcoop.org/job/iron-horse/1230/ 17:34:20 <DevZone> Project xussrset - Trains from Russia build #840-push: SUCCESS in 3 min 36 sec: https://jenkins.openttdcoop.org/job/xussrset/840/ 18:06:44 <DevZone> Project Iron Horse build #1231-push: SUCCESS in 4 min 18 sec: https://jenkins.openttdcoop.org/job/iron-horse/1231/ 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: https://jenkins.openttdcoop.org/job/worldairlinersset/903/ 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: https://jenkins.openttdcoop.org/job/xussrset/841/ 23:52:15 *** yorick has quit IRC