Times are UTC Toggle Colours
00:02:40 *** davis has joined #openttdcoop.devzone 00:04:22 <Brot6> #openttdcoop Client Patch Pack - Revision 22:db214981e765: Fix: confuse the comments (Ammler) @ http://dev.openttdcoop.org/projects/clientpatches/repository/revisions/db214981e765 01:32:26 *** davis has quit IRC 05:22:33 *** Yexo has quit IRC 05:29:16 *** Yexo has joined #openttdcoop.devzone 07:05:39 <Brot6> NewGRF Meta Language - Feature #1031: support for houses (planetmaker) @ http://dev.openttdcoop.org/issues/1031#change-3947 07:07:35 <Brot6> NewGRF Meta Language - Feature #1031: support for houses (planetmaker) @ http://dev.openttdcoop.org/issues/1031#change-3947 07:30:24 *** ODM has joined #openttdcoop.devzone 07:38:22 <planetmaker> @base 16 10 6D 07:38:22 <Webster> planetmaker: 109 07:40:36 <Brot6> NewGRF Meta Language - Feature #1031: support for houses (planetmaker) @ http://dev.openttdcoop.org/issues/1031#change-3948 07:42:12 <Yexo> planetmaker: you change size from 2 to 1 07:42:45 <planetmaker> hm size needs to be two, yes 07:43:18 <planetmaker> does it make sense, though? 07:43:31 <planetmaker> it looks IMHO a bit like a hack. But I see no other sensible way 07:44:53 <Yexo> could you change the documentation to include also close tags for all html? 07:45:16 <planetmaker> uh... why that? HTML doesn't require that? 07:45:22 <planetmaker> and it makes the source quite unreadable 07:45:25 <Yexo> I've converted some of the old documentation, but it's a lot of work and can better be done when writing it 07:45:49 <Yexo> the code can be made more readable by splitting it over multiple lines 07:45:49 <planetmaker> hm. I thought we agreed to skip all the needless closing tags in tables 07:45:56 <Yexo> did we? 07:45:58 <Yexo> oh 07:45:59 <Rubidium> planetmaker: neither do NewGRFs need a version :) 07:46:27 <Rubidium> and later HTMLs kinda need it (e.g. xhmtl) 07:46:41 <planetmaker> Rubidium: Yexo even the wt3 example doesn't have the closing tags on <td> etc 07:46:59 <planetmaker> that's why I consider it quite not needed 07:47:14 <Yexo> ok, leave it this way for now 07:47:58 <planetmaker> s/wt3/w3c/ 07:50:38 <planetmaker> http://www.w3.org/TR/html401/struct/tables.html 07:50:40 <Webster> Title: Tables in HTML documents (at www.w3.org) 07:53:19 <Yexo> maiL_acceptance <- in reference.html, should be lowercase L 07:53:51 <Yexo> availability_mask could do with a more descriptive description, like explaining the CLIMATE_SNOW bit 07:55:07 <Yexo> override should be listed directly under substitute 07:55:32 <Yexo> accepted_cargo needs more documentation and belongs next to the *_acceptance values 07:57:16 <Yexo> animation_speed: documentation doesn't match code, and I'm not sure that the documentation is a good way of defining this property 07:57:58 <planetmaker> ah, right. Not sure the code is a good way either :-) 07:58:13 <Yexo> true, but you can't set it to "multiples" of 108ms 07:58:19 <Yexo> only to powers of 2 times 108ms 07:58:26 <planetmaker> yes 2**n * 108 07:59:28 <Yexo> max value in seconds would be 1769 (according to ttdpatch wiki), so 1300 seconds would be rounded to either 880 or 1770 which is quite a lot 07:59:30 <planetmaker> would make rounding to the nearest of 2**n * 0.108 make sense? 08:00:37 <Yexo> I'd say just leave it as in the code and create a table in the documentation that maps the value to seconds 08:00:43 <planetmaker> ok 08:01:43 <Yexo> industry tiles, objects and airport tiles have the same properties for animation 08:01:54 <planetmaker> good to know :-) 08:07:32 <planetmaker> @calc 2**8*0.108 08:07:32 <Webster> planetmaker: 27.648 08:07:42 <planetmaker> @calc 0.108 * 2**9 08:07:42 <Webster> planetmaker: 55.296 08:08:56 <planetmaker> @calc 0.108 * 2**14 08:08:56 <Webster> planetmaker: 1769.472 08:32:52 <Brot6> NewGRF Meta Language - Revision 782:3dd59f5ca227: Change: Re-define 'availability_mask' as a cust... (planetmaker) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/3dd59f5ca227 08:32:52 <Brot6> NewGRF Meta Language - Revision 783:f0a99108991b: Doc: Add documentation for house properties (planetmaker) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/f0a99108991b 08:42:51 <Brot6> NewGRF Meta Language - Feature #1031: support for houses (planetmaker) @ http://dev.openttdcoop.org/issues/1031#change-3950 08:45:31 <Yexo> planetmaker: for animation speed 2 means 108ms 08:45:43 <Yexo> 1 means 54ms, 0 means 27ms 08:46:00 <Yexo> for houses the minimum value is 2 08:46:26 <Brot6> NewGRF Meta Language - Feature #1031: support for houses (yexo) @ http://dev.openttdcoop.org/issues/1031#change-3951 08:49:48 <planetmaker> ups 08:52:35 <planetmaker> is it the same for industry and airport tiles? 08:53:09 <Yexo> no, the mimimum for those is 0 08:53:12 <planetmaker> hm not quite nvm 08:53:14 <planetmaker> yes 08:53:23 <planetmaker> fixing that now 08:57:51 <Rubidium> actually, in OpenTTD it's be a factor 0.12 08:58:05 <Rubidium> (or 30ms per tick) 08:58:24 <Rubidium> so it might be better to specify the animation speed in ticks instead of seconds 09:00:09 <planetmaker> He... 09:00:20 <Brot6> NewGRF Meta Language - Revision 784:f9b7edd199c5: Fix (r783, r782): Off-by-two error in animation... (planetmaker) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/f9b7edd199c5 09:00:50 <planetmaker> @calc 0.27/0.3 09:00:50 <Webster> planetmaker: 0.9 09:12:11 <planetmaker> http://img.openttdcoop.org/images/bildscnjn.png <-- like that Rubidium ? 09:14:29 <Rubidium> I really think that the time in seconds isn't very useful 09:14:40 <Rubidium> "It doesn't work in fast forward" 09:14:59 <Rubidium> also 2**16 != 65526 09:15:15 <planetmaker> @calc 2**16 09:15:15 <Webster> planetmaker: 65536 09:15:19 <planetmaker> :-) 09:15:42 <planetmaker> Well. In FF the animation length is also not important 09:17:13 <planetmaker> animation is only interesting in normal game play, is it? 09:17:46 <Rubidium> it is always executed 09:17:53 <planetmaker> of course 09:18:15 <planetmaker> "The time is given as reference, assuming normal game speed." ? 09:18:35 <planetmaker> then it will even remain true when there's some weired daylength patch active 09:18:43 <planetmaker> unless it messes with ticks 09:20:16 <Rubidium> I also think that you're pretty quickly losing track of how long e.g. 110.592 seconds is 09:20:27 <Rubidium> @calc 110.592/1998 09:20:27 <Webster> Rubidium: 0.0553513513514 09:20:52 <planetmaker> what would be better? minutes? Ingame time? 09:20:53 <Rubidium> about 55.4 game days 09:21:29 <Rubidium> although "about 55 days" would be a reasonable explanation 09:21:41 <Rubidium> s/explanation/rounding/ 09:22:11 <planetmaker> I'll add an ingame column additionally. Also assuming normal game speed ;-) 09:22:48 <Rubidium> the game speed doesn't matter 09:23:02 <Rubidium> except if you mess with a daylength patch, but that's not quite supported 09:23:17 <planetmaker> 74 ticks a day, right? 09:23:21 <Rubidium> yes 09:23:23 <planetmaker> @calc 1/24*24 09:23:23 <Webster> planetmaker: 1 09:23:30 <planetmaker> @calc 1/74*24 09:23:30 <Webster> planetmaker: 0.324324324324 09:23:33 <planetmaker> @calc 1/74*24*60 09:23:33 <Webster> planetmaker: 19.4594594595 09:24:22 <planetmaker> @calc 4/74*24*60 09:24:22 <Webster> planetmaker: 77.8378378378 09:24:45 <Rubidium> you're using in-game minutes? 09:24:50 <planetmaker> why not? 09:25:07 <Rubidium> it's used like nowhere 09:25:07 <planetmaker> fractions of a day don't sound sensible 09:25:11 <planetmaker> I know 09:25:24 <planetmaker> but 0.03 days mean nothing to me 09:25:48 <Rubidium> then only use it when ticks > 74 09:26:05 <Rubidium> @calc 128/74 09:26:05 <Webster> Rubidium: 1.72972972973 09:26:19 <planetmaker> @calc 0.729*24 09:26:20 <Webster> planetmaker: 17.496 09:26:35 <Rubidium> rather about 2 days 09:26:48 <Rubidium> oh, and for fun: http://wiki.ttdpatch.net/tiki-index.php?page=GameSpeed 09:27:21 <planetmaker> that's why I added 'normal game speed' 09:27:27 <Rubidium> or if you want precision, just use 1.7 days 09:27:37 <planetmaker> When people temper with that... not my problem. Nor the grf author's 09:28:11 <planetmaker> I don't like fractional days more detailed than half given as decimal 09:28:27 <planetmaker> in any UI or documentation 09:30:00 <Rubidium> but hours and minutes is going to give trouble with those virtual time things 09:30:30 <planetmaker> why? 09:31:01 <planetmaker> unless it changes the ticks per day it won't 09:31:24 <planetmaker> and a daylength patch which doesn't change the ticks per day won't change the real issue with introduction dates 09:32:00 <Rubidium> you have that nice clock in the bottom, so if you say every 1 hour and 20 minutes, they're going to look at THAT clock... now at 1/Nth of a game day 09:32:05 <Rubidium> s/now/not/ 09:32:32 <planetmaker> hm? 09:32:40 <planetmaker> that would be appropriate, would it? 09:32:45 <Rubidium> I guess you might better just drop the whole... how long does 2**n ticks actually take? 09:33:05 <planetmaker> it's supposed to give a reference under normal conditions 09:33:06 <Rubidium> planetmaker: no, because with 1 tick = 1 second it's not going to be anywhere close 1 hour and 20 minutes 09:34:17 <Rubidium> but does such a reference need up to 7 decimals of precision? 09:34:55 <Rubidium> 11: about 1 minute, 12: about 2 minutes, 13: about 4 minutes, 14: about 8 minutes, 15: about 15 minutes, 16: about 30 minutes 09:35:16 <Rubidium> much more readable and relatable than 1769.472 seconds 09:35:19 <planetmaker> Rubidium: adaptive precision 09:35:32 <planetmaker> 20 minutes, 40, 1:20, 2.5 hours, ... 09:35:57 <planetmaker> or rather 20, 40, 1:20, 2.5 hours,... 09:36:03 <planetmaker> s/40/39/ 09:36:04 <Rubidium> still, better drop my idea to relate it to in-game days 09:36:12 <planetmaker> I like it though 09:36:16 <planetmaker> that's what is important 09:36:26 <planetmaker> that's what I'm interested in 09:36:34 <planetmaker> or in the real-life change frequency 09:36:47 <Rubidium> but it's going to be confusing if we ever decided to go with the virtual clock, or at least when you use hours and minutes 09:37:25 <planetmaker> Rubidium: that's why I add "assuming normal game speed" 09:37:30 <planetmaker> and "for reference only" 09:37:39 <planetmaker> I don't think it's confusing 09:37:56 <planetmaker> Besides, can you explain me the 'virtual clock'? 09:38:05 <planetmaker> What effect does it have on game play? 09:38:19 <Rubidium> http://www.tt-forums.net/viewtopic.php?f=33&t=49799 09:38:22 <Webster> Title: Transport Tycoon Forums • View topic - [Patch] Virtual time (at www.tt-forums.net) 09:38:27 <Rubidium> http://www.tt-forums.net/viewtopic.php?f=33&t=49956 09:38:31 <Webster> Title: Transport Tycoon Forums • View topic - [Patch] Departure boards, 24h clock (+ binary) (at www.tt-forums.net) 09:38:40 <Rubidium> http://www.tt-forums.net/viewtopic.php?f=33&t=39276&start=0 09:38:41 <Webster> Title: Transport Tycoon Forums • View topic - [Patch] Improved Timetable Management [V2.31tr SVN15778] (at www.tt-forums.net) 09:39:06 <planetmaker> so... does it change the number of ticks per day? 09:39:10 <Rubidium> NO 09:39:21 <planetmaker> then it should be fine always 09:39:40 <Rubidium> it makes a virtual clock, which is just another representation of _date + _date_fract 09:39:57 <planetmaker> then I especially don't see an issue with displaying time length in minutes 09:39:59 <Rubidium> and visualises that with a clock like structure, e.g. 01:23:45 09:40:26 <Rubidium> which is added *next* to the game date in the status bar 09:41:24 <planetmaker> that's quite fine, is it? 09:41:47 <Rubidium> and thus if you talk about 20 minutes, I'd immediately reckon that it's the 01:23:45 part of the status bar and not a fraction of the 01-02-2000 "date" 09:41:54 <planetmaker> I fail to see how it interferes to a rough estimate for an animation length give in a grf coding tool, though 09:42:10 <planetmaker> yes, but it's the same? 09:42:15 <Rubidium> NO, it's not 09:42:19 <planetmaker> ? 09:42:32 <Rubidium> the virtual time uses something like 1 tick = n seconds (1 <= n <= 5) 09:43:38 <Rubidium> thus 20 minutes would be 1200 ticks 09:43:57 <Rubidium> (assuming n = 1) 09:45:07 <planetmaker> you lost me there. Still 74 ticks an ingame day. But 1 tick = n seconds real? 09:45:24 <Rubidium> no, I'm talking about ***virtual*** 09:45:59 <Rubidium> as in, how it is showed in that ***virtual*** in-game clock, which is another representation of ticks 09:46:08 <Rubidium> it has NOTHING to do with real seconds 09:46:17 <Rubidium> nor with in-game days nor with real days 09:46:46 <planetmaker> so... the 24hours of a virtual day can well be 13 ingame days? 09:47:59 <Rubidium> yes... but in the current implementations it's starting with 24 virtual hours ~= 233 days up to 3 years and 73 days 09:48:39 <planetmaker> hm. I don't like that a single bit. It's bound to become confusing 09:49:20 <Rubidium> yes, but needed if you want to make it possible for humans to efficiently make timetables 09:49:28 <planetmaker> yes 09:50:12 <planetmaker> Though it's well possible to do that with the ingame time, using kinda the same interface 09:50:23 <planetmaker> Just the numbers look a bit funny. But confusion is largely reduced 09:50:43 <Rubidium> yes, but now set the start date of 3 trains with a 28 day interval 09:51:06 <planetmaker> yes? 09:51:16 <planetmaker> Use day-of-year 09:51:35 <Rubidium> that's still unintuitive 09:51:45 <planetmaker> as is double time-standard 09:51:52 <planetmaker> that's much worse 09:52:08 <Rubidium> well, you're only using the virtual clock for the timetables, so there is only one time 09:52:19 <planetmaker> And there's the date 09:52:40 <planetmaker> And possibly a daylength patch stretching it 09:52:41 <Rubidium> but the date's not used for anything besides autosave and financial stuff 09:52:53 <planetmaker> and all vehicle introduction 09:52:58 <planetmaker> and industry introduction etc 09:53:14 <Rubidium> and daylength stretching days would actually benefit from a virtual clock as that will stay the same, whereas days would be much bigger 09:53:22 <planetmaker> which is IMHO the real issue about day length: all things get introduced in no time and then I play 500 years with all vehicles expired 09:53:27 <Rubidium> unless you're going to work with half-days to keep the same granularity 09:55:01 <planetmaker> ok, so it's fractional days in the explanation 09:57:32 <planetmaker> http://img.openttdcoop.org/images/bildsceue.png 09:59:39 <Rubidium> maybe do something similar with the length in seconds (and I'm not sure about the need for the distinction between TTDP and OTTD) 10:02:02 <Rubidium> 5: 0.9s, 4: 0.45s, 3: 0.22s, 2: 0.11s, 1: 0.06s, 0: 0.03s, 6: 1.8s, 7: 3.5s, 8: 7s, 9: 14s, 10: 28s, 11: 1 minute, 12: 2 minutes, 13: 4 minutes, 14: 7.5 minutes, 15: 15 minutes, 16: 30 minutes 10:02:22 <planetmaker> good idea, yes 10:02:41 <planetmaker> I'll just use OpenTTD values then and skip TTDP 10:05:42 <Rubidium> if you're rounding values, round them down a bit :) 10:05:54 <planetmaker> why? 10:06:04 <Rubidium> so it's between TTDP and OpenTTD's values 10:06:28 <Rubidium> then the TTDPatch nutcases can't say that NML is for OpenTTD 10:08:21 <planetmaker> :-) 10:08:41 *** ODM has quit IRC 10:14:32 <Hirundo> and never ever use 'TTDP' in nml documentation instead of 'TTDPatch' :) 10:15:23 <planetmaker> http://img.openttdcoop.org/images/bildscjrj.png <-- any last comments on the table? 10:15:50 <planetmaker> haha @ Hirundo. I found it noteworthy though that Lakkie corrected it to TTDPatch, but retained the order ;-) 10:16:28 <Yexo> table looks fine 10:26:20 <planetmaker> comitted 10:27:49 <Brot6> NewGRF Meta Language - Revision 785:b7c4eba91b86: Doc: Be more verbose on what the individual ani... (planetmaker) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/b7c4eba91b86 10:41:07 <Ammler> well, TTDP - OTTD / TTDPatch - OpenTTD 10:42:05 <Ammler> it looks silly, if you use TTDPatch - OTTD 10:44:28 <planetmaker> yes. OpenTTD / TTDPatch looks nice, too 10:47:58 <planetmaker> In written Text I'd prefer that over the short of OTTD / TTDP 10:48:53 <Ammler> why are "tickspeeds" different? 10:49:29 <planetmaker> eh? 10:50:58 <Ammler> 0.027 - 0.03 10:59:37 *** KenjiE20 has joined #openttdcoop.devzone 12:28:32 <Brot6> 2cc train set - Feature #1503 (New): 4-4-0 American (Voyager1) @ http://dev.openttdcoop.org/issues/1503 12:59:11 *** Webster has joined #openttdcoop.devzone 13:26:06 <Brot6> OpenGFX+ Trees - Revision 19:e260d90cf51c: Added tag 0.2.0 for changeset aeb654e5caae (Froix) @ http://dev.openttdcoop.org/projects/ogfx-trees/repository/revisions/e260d90cf51c 13:26:06 <Brot6> OpenGFX+ Trees - Revision 20:732ebc79a354: Removed tag 0.2.0 (Froix) @ http://dev.openttdcoop.org/projects/ogfx-trees/repository/revisions/732ebc79a354 13:26:06 <Brot6> OpenGFX+ Trees - Revision 21:384f4f6537f5: Feature: Added ability to disable any number of trees.... (Froix) @ http://dev.openttdcoop.org/projects/ogfx-trees/repository/revisions/384f4f6537f5 13:27:04 <planetmaker> o_O 13:27:53 <planetmaker> learn the beauty of 'rollback' is the next lesson, I guess ;-) 13:30:23 <planetmaker> and more important: "don't run nforenum on the pnfo file :-( 13:31:25 <planetmaker> or probably only 'stop caring about sprite numbers' 13:32:28 *** Froix has joined #openttdcoop.devzone 13:32:43 <planetmaker> hi Froix 13:32:50 <Froix> hey 13:32:52 <planetmaker> Please don't update sprite numbers in the pnfo file 13:32:56 <planetmaker> they're pointless 13:33:14 <Froix> i work with nfo and just copy the whole thing inside pnfo 13:33:23 <Froix> make compiles reaaaaallly slow 13:33:29 <planetmaker> :-( 13:33:43 <planetmaker> even then: no need to update the sprite numbers 13:34:11 <Froix> nforenum updates them 13:34:17 <planetmaker> yes. I know 13:34:42 <planetmaker> but no need to update them in the source file 13:35:30 <Froix> i can choose not to update the sprite numbers when i paste the whole nfo code inside pnfo? 13:35:44 <planetmaker> run nforenum with -k 13:35:50 <Froix> ah ok! 13:36:02 <planetmaker> and grfcodec the .new.nfo file 13:36:20 <Froix> ok 13:36:26 <Froix> i got it :) 13:36:29 <planetmaker> how long does compilation with make take for you? 13:36:38 <planetmaker> I know it's slow on windows... 13:36:54 <Froix> just about a minute 13:37:09 <planetmaker> that's terribly long :-( 13:37:18 <planetmaker> what windows do you have? 13:37:30 <Froix> xp sp3 13:37:41 <planetmaker> hm. 13:37:58 <planetmaker> I guess I'll really have to get one in my VM and test that more 13:41:51 <planetmaker> and I have another question, Froix : do you know the beauty of 'hg rollback'? :-) 13:42:03 <Froix> is that the same as the revert thing? 13:42:29 <planetmaker> basically yes. It works only for the last commit. And as long as it hasn't been pushed 13:42:48 <planetmaker> so.. maybe not 'yes', but stronger ;-) 13:42:54 <planetmaker> revert undoes changes not commited 13:42:59 <planetmaker> rollback undoes a commit 13:43:05 <Froix> ah ok 13:43:15 <planetmaker> I think you could have used it :-P 13:43:41 <Froix> i sure could have but there's no real damage done is there? 13:44:00 *** thgergo has joined #openttdcoop.devzone 13:44:24 <planetmaker> removing tags is a bit undesired thing. But no real damage done 13:44:57 <Froix> ah ok. didn't realize that was pushed along. :) 13:45:06 <Froix> was just trying it out 13:45:55 <planetmaker> hm... actually the better thing than r20 would have been to remove the .hgtags file 13:46:02 <planetmaker> but that's unintuitive. 13:47:18 <Froix> still good to know there's that 13:47:53 <planetmaker> with tags it's a bit special: hg rollback and then a hg revert .hgtags is needed 13:48:05 <planetmaker> when you test tags 13:48:12 <Froix> ok. tnx 13:48:43 <planetmaker> yes, I found out the hard way myself just the other day :-P 13:48:54 <planetmaker> rollback was not enough 13:50:47 <planetmaker> Froix, would you care or mind, if I converted the trees into an NML project? 13:51:09 <planetmaker> hm... did I ask that already? Might have... 13:52:02 <Froix> let me try running nml code on my pc first :) 13:55:09 <planetmaker> checkout swedishrails and NML ;-) 13:55:22 <Froix> i just cloned it :) testing it now 13:55:35 <planetmaker> in principle I have the feeling that NML is slightly faster than renum + grfcodec 13:55:45 <planetmaker> BUT there is the makefile, of course, too... 13:56:00 <planetmaker> which is basically the same. It can also be skipped. Somewhat 13:56:33 <planetmaker> But one needs to assemble the NML file from it's pieces, which one could do by hand using gcc 13:57:14 <Froix> i'm missing something - http://pastebin.com/pn3WCfdx 13:57:59 <planetmaker> yes, you're missing a somewhat recent version of grep 13:58:19 <planetmaker> and nmlc is not in your path either 13:58:33 <planetmaker> (which is the name of the nml compiler) 13:59:07 <Froix> ok i'll look into it 13:59:09 <planetmaker> you can get around that, if you edit a Makefile.local and add the path to nmlc there 13:59:22 <planetmaker> grep... is more serious, though 14:00:11 <planetmaker> http://gnuwin32.sourceforge.net/packages/grep.htm <-- might give you a new enough grep. But I'm not sure where -o got introduced 14:00:17 <Webster> Title: Grep for Windows (at gnuwin32.sourceforge.net) 14:00:32 <Froix> yeah i'm already there 14:00:41 <planetmaker> I wonder though, don't you have the same issue with the nfo then? 14:01:02 <Froix> no i haven't heard of grep til now 14:01:28 <Froix> is that supposed to come in with gcc and g++? 14:01:54 <planetmaker> it should come with mingw. And you have it ;-) 14:02:01 <planetmaker> But obviously a too old version of grep 14:02:34 <Froix> i see 14:19:57 <planetmaker> http://pastebin.org/941335 <-- Froix if you want to test NML only, use that NML file 14:20:17 <planetmaker> place it in the main dir of swedish rails and run "nmlc swedishrails.nml" 14:20:41 <planetmaker> (assuming that nmlc is in your search path, of course) 14:21:01 <Ammler> Froix: mingw or cygwin? 14:21:44 <Ammler> mingw should be setup like the wiki tells and it works 14:22:02 <planetmaker> it does work, Ammler 14:22:10 <Ammler> I read something with grep 14:22:10 <planetmaker> it just has a too old grep 14:22:33 <planetmaker> it doesn't recognize -o 14:22:36 <Ammler> then he might not have used the wiki to setup 14:22:48 <planetmaker> which is a version issue with some mingw versions. 14:22:55 <Froix> ammler! hey! i have mingw 14:23:07 <Froix> grep works ok now. 14:23:15 <Froix> how do i install nmlc 14:23:32 <Ammler> planetmaker: that is for the "old" dep check? 14:23:56 <planetmaker> Froix, currently the best way is to make a checkout of nml 14:24:02 <Ammler> maybe I didn't recocnize because I have python installed 14:24:17 <planetmaker> Ammler, can be that it's the old style, yes 14:24:36 <Ammler> for nml, you need python anyway... 14:25:15 <Froix> checkout? 14:27:46 <planetmaker> similar path as the trees or swedish rails 14:27:48 <planetmaker> just nml 14:28:12 <planetmaker> then it will be easy to update it ;-) 14:29:13 <planetmaker> hg clone http://mz.openttdcoop.org/hg/nml 14:29:24 <Ammler> hmm, did Terkhen document how he made his mingw nml ready? 14:29:35 <planetmaker> partially, I think 14:29:44 <Terkhen> I still haven't tried nml with mingw 14:29:50 <Ammler> he, you like to spread that 10 years old domain :-P 14:30:26 <planetmaker> :-P 14:30:47 <planetmaker> s/mz/dev/ :-) 14:30:57 <Ammler> or hg 14:32:49 <Brot6> #openttdcoop - Membership #1502 (Closed): Applying for project: AI-Trans (fanioz) @ http://dev.openttdcoop.org/issues/1502 14:32:49 <Brot6> #openttdcoop - Membership #1502 (Closed): Applying for project: AI-Trans (Ammler) @ http://dev.openttdcoop.org/issues/1502#change-3952 14:35:43 <planetmaker> Ammler, ^ why is there the thing quoted twice? 14:36:00 <planetmaker> it's an unnecessary hightlight for fanioz 14:36:07 <Ammler> the status of fanioz thread changed 14:36:13 <Ammler> and my note 14:36:22 <planetmaker> yes. But one modification would suffice as it's one edit, right? 14:36:29 <Ammler> no, 2 14:36:37 <planetmaker> close + text = one action 14:36:39 <Ammler> status (1), my note (2) 14:36:52 <planetmaker> Has it always been this way? 14:37:11 <Ammler> that happens, if the creating of the ticket is in last 10 feeds 14:37:28 <Ammler> and since we have different feeds, this can happen more likely 14:37:42 <planetmaker> what different feeds? 14:37:54 <Ammler> !rss list 14:37:54 <Brot6> Ammler: 32bpp (devzone) (watched), a51 (devzone), administration (devzone) (watched), aidev (devzone) (watched), basesets (devzone) (watched), devactivity (devzone), grftools (devzone) (watched), newgrfs (devzone) (watched), osqc (devzone), patches (devzone) (watched) 14:38:00 <Ammler> those were 1 before 14:38:21 <planetmaker> hm. and why so many? 14:38:32 <Ammler> one per category 14:38:38 <planetmaker> I find it slightly irritating to always get two notifications for one action 14:38:41 <Ammler> well, not every feed is watched here 14:38:47 <planetmaker> yes, true 14:39:19 <Ammler> well in the case before, it doesn't hurt, that fanioz got a highlight, if he would be here 14:39:44 <Ammler> so he would see, his request got accepted 14:40:19 <planetmaker> Well. Still I think it's a needless double quote Brot does nearly on every change 14:40:48 <Ammler> well, alternative is to disable it, chose :-P 14:40:52 <planetmaker> The same also then applies to a commit which closes the thing. Also two notifications 14:41:09 <Ammler> well, on newgrfs, this happens rarly 14:41:30 <Ammler> only if you open a ticket and fix it right after 14:41:47 <Ammler> else there are mostly 10 other feeds between 14:42:45 <Ammler> anyway, everyone is welcome to contribute patches to redmine 14:42:51 <Ammler> we use already quite some 14:43:01 <planetmaker> he, do we? 14:43:23 <Ammler> the whole HG-MQ and around 2 from me 14:43:35 <Rubidium> hell, you're even using a heavily patched OpenTTD (r1) 14:43:52 <Ammler> :-D 14:44:25 <Ammler> (and I still have no clue about ruby) 14:44:26 <planetmaker> :-D 14:45:17 <Ammler> I just installed a NDAS disk 14:45:43 <Ammler> which is based on 2.4 kernel and further development is based on patches... 14:46:03 <Ammler> and there were not 1 patch, you needed to install tons of patches, like commits 14:53:00 *** ODM has joined #openttdcoop.devzone 14:55:55 <Ammler> planetmaker: http://www.tt-forums.net/viewtopic.php?f=26&t=50095 <-- opengfx+ grf? 14:55:57 <Webster> Title: Transport Tycoon Forums • View topic - [OTTD] Big GUI (Double Sized GUI) [WIP] (at www.tt-forums.net) 14:57:39 <planetmaker> yes :-) 14:58:02 <planetmaker> maybe you can propose that. Zephyris will be susceptible to the title, I guess :-) 15:10:31 <Hirundo> The NML documentation states that the vehicle prop cargo_type can be any cargo label. Is that really true? 15:11:08 *** Yexo_ has joined #openttdcoop.devzone 15:12:58 *** frosch123 has joined #openttdcoop.devzone 15:14:58 *** Yexo is now known as Guest1094 15:14:58 *** Yexo_ is now known as Yexo 15:15:41 *** Froix has quit IRC 15:17:58 <Ammler> planetmaker: the openttd.org wiki would be a good place for OpenGFX with the OpenGFX+, if it wouldn't be the readme :-P 15:17:58 *** Guest1094 has quit IRC 15:18:36 <Brot6> 2cc train set - Feature #1503: 4-4-0 American (Voyager1) @ http://dev.openttdcoop.org/issues/1503#change-3954 15:19:02 <planetmaker> Hirundo, it's my understanding... or do you think it can only be one of the default ones? 15:19:21 <planetmaker> Ammler, what do you mean? 15:19:28 <Hirundo> IIRC It's one of those nfo quirks, that the cargo type is not translated there 15:19:51 <planetmaker> I think it is - under certain circumstances. But I might recall wrong 15:20:09 <frosch123> default cargo type is not translated :) 15:20:22 <Ammler> planetmaker: transfering the wiki from readme to a "OpenGFX Portal" 15:20:55 <Brot6> 2cc train set - Feature #1504 (New): 4-6-0 Ten-wheeler (Voyager1) @ http://dev.openttdcoop.org/issues/1504 15:21:09 *** Alberth has joined #openttdcoop.devzone 15:21:34 <planetmaker> frosch123, now that I read the page again: is it correct that it need not be set and then the default cargo type is the first refit option? 15:22:55 <planetmaker> or asked differently: what does one loose if that property is not exposed? 15:23:02 <planetmaker> it's somewhat fishy anyway 15:23:03 <frosch123> if plain nfo you have to set it to 0xFF 15:23:24 <planetmaker> so... it does make sense to always set it to 0xFF? 15:23:43 <planetmaker> _if_ NML gives a way to define the first refittable cargo? 15:24:14 <planetmaker> (or maybe it should stay, but... strongly discourage people to use it ;-) ) 15:24:26 <frosch123> there is no way to set the 'first' refittable cargo 15:24:34 <planetmaker> hm, ok 15:25:08 <planetmaker> and it'd be a feature request to change this property or add a new one which allows to define the default cargo type via the CTT? 15:25:21 <frosch123> you only need that property if your vehicle is not refittable 15:25:46 <planetmaker> which hardly any newgrf needs... 15:25:58 <frosch123> something like: set to 0xFF if the vehicle carries something, set to 0x00 if the vehicle does not carry something 15:26:07 <frosch123> planetmaker: train engines :) 15:26:21 <planetmaker> re-gearing? 15:26:51 <frosch123> re-gearing also means to carry something 15:27:04 <frosch123> even though you can set the capacity to 0 via cb 36 (ottd only) 15:27:11 <planetmaker> ok, then I don't see how engines need this 15:27:35 <frosch123> if you set a vehicle to 'first refittable' and it is not refittable to anything, the vehicle is disabled 15:27:51 <planetmaker> ah, that's the missing piece of information :-) 15:27:53 <frosch123> e.g. lv4 refridgerated truck is disabled unless there is something like food 15:28:02 <planetmaker> nifty 15:28:18 <frosch123> messy :) 15:30:13 <frosch123> you could rename the property to "disable if no cargo available" 15:30:42 <frosch123> hmm, no, not true 15:31:06 <frosch123> there is another special case: trucks and busses are determined by the cargo of the first vehicle, even if it does not carry something :p 15:32:09 <planetmaker> omg... 15:33:15 <planetmaker> if I set it to 0xFF on such bus - what would happen? refit determined by 2nd part? 15:33:37 <planetmaker> or also disabled? 15:33:39 <frosch123> 0xFF means use first cargo, disable if none 15:34:09 <planetmaker> oh... they have capacity 0, but carry... passengers 15:34:24 <frosch123> 0 means, use 0 if no refitmask, or use first cargo if refitmask (latter might be ottd only) 15:35:17 <Brot6> Town Names - Feature Request #1505 (New): Portuguese Town Names (vanadio) @ http://dev.openttdcoop.org/issues/1505 15:35:48 * frosch123 ponder drawing a decision graph with graphviz or so 15:36:42 <planetmaker> :-) That might be something to add to the documentation of NML. Seems it's needed after all. 15:37:19 <Ammler> how is the sed to replace last space with tab? 15:37:47 <frosch123> s/ \([^ ]*\)$/\t/ 15:38:01 <frosch123> does not sound useful though :p 15:38:28 <Ammler> you sed or my question? 15:38:32 <Ammler> your* 15:38:33 <frosch123> your question 15:38:47 <Rubidium> Ammler: don't forget to convert it to utf-8 :) 15:39:08 <Ammler> :-) 15:47:42 <frosch123> hmm, i thought wallyweb agreed that "TTDX" and "OTTD" object classes are pointless 15:49:01 * planetmaker had that impression, too 15:51:00 <Ammler> Alberth: I have a grf but how shall I confirm, it works as intendend? 15:51:02 <frosch123> let's wait for mb to rage delete it :) 15:51:13 <planetmaker> :-) 15:51:18 <Ammler> town names with > 255 entries 15:51:32 <planetmaker> Ammler, test it on 2048^2 15:51:40 <planetmaker> with high-density towns 15:51:51 <Alberth> write a grf -> nml converter :p 15:51:55 <planetmaker> hm... with high town density 15:52:04 <planetmaker> lol @ Alberth :-) 15:52:08 <Ammler> hehe 15:52:20 <planetmaker> please sign here: __________________ 15:52:24 <Ammler> the resulting nfo doesn't have nice formatting 15:52:38 <planetmaker> grfcodec -d? 15:52:49 <Ammler> no, the one from nml 15:52:59 <planetmaker> well. Use grfcodec -d then 15:53:18 <Ammler> not better 15:53:26 <planetmaker> it's also 'safer' as it is really testing the grf and not subject to potential nml->nfo conversion problems 15:54:07 <planetmaker> (except that it - of course - tests grfcodec's de-compilation routing ;-) ) 15:54:10 <Ammler> oh wow, does nml add the utf-8 only where needed? 15:54:32 <planetmaker> really? 15:54:38 <Alberth> yeah, grfcodec, and look at the result should work too. I was pondering to write an alternative nml that generates the same output, but that may not be very useful 15:54:58 <Ammler> I have "C3 9E" only with Umlauts names 15:55:24 <Alberth> I'd have to read the source to say anything on that :) 15:56:19 <frosch123> [17:52] <Ammler> the resulting nfo doesn't have nice formatting <- use grf2html :p 15:58:16 <Ammler> frosch123: BUG! :-) 15:58:31 <Ammler> 0x01 (0/2 = 0.000%) "Oberbipp" 15:59:47 <frosch123> whole grf or it did not happen :) 16:02:59 <Ammler> Alberth: I guess, it doesn't work 16:03:06 <Ammler> I push my test 16:03:26 <planetmaker> push the limits :-P 16:03:59 <Yexo> <Ammler> oh wow, does nml add the utf-8 only where needed? <- yes, I changed that last week or so 16:04:11 <Brot6> Swiss Town Names - Revision 15:0633d740ec2f: Change: no dummy entries needed anymore (Ammler) @ http://dev.openttdcoop.org/projects/swisstowns/repository/revisions/0633d740ec2f 16:04:11 <Brot6> Swiss Town Names - Revision 16:078a73d6ad5f: Feature: exit/abort if nml wasn't able to build the grf (Ammler) @ http://dev.openttdcoop.org/projects/swisstowns/repository/revisions/078a73d6ad5f 16:04:12 <Brot6> Swiss Town Names - Revision 17:38ba3997c8f0: Fix: grf{} requires version (Ammler) @ http://dev.openttdcoop.org/projects/swisstowns/repository/revisions/38ba3997c8f0 16:04:13 <Brot6> Swiss Town Names - Revision 18:85b3b623b30a: Change: use the internal split of nml (Ammler) @ http://dev.openttdcoop.org/projects/swisstowns/repository/revisions/85b3b623b30a 16:04:14 <Ammler> some bytes smaller :-) 16:05:55 <Ammler> Yexo: but afaik, Umlauts are in the "nfo codepage" 16:06:24 <Yexo> Ammler: currently it's just testing ord(c) < 128 16:06:38 <Ammler> I didn't use utf-8 at all on the old nfo code 16:07:04 <Ammler> ic 16:07:05 <Yexo> so only strings with all bytevalues < 128 are considered non-utf-8 16:10:38 <Brot6> Portuguese Town Names - Feature Request #1505 (New): Portuguese Town Names (vanadio) @ http://dev.openttdcoop.org/issues/1505 16:11:28 <frosch123> Part 0 Use bits 0 to 0 (1 bits) <- Ammler: does not look like a grf2html bug, either a grfbug or a nml bug 16:12:46 <Ammler> well, in 7 mins, we have the grf and nfo 16:14:12 <Brot6> repository /home/ottdc/hg-repos/portuguesetowns registered in Redmine with url /home/ottdc/hg-repos/portuguesetowns 16:14:12 <Brot6> repository /home/ottdc/hg-repos/portuguesetowns created 16:15:11 *** blinky has joined #openttdcoop.devzone 16:15:30 *** blinky has left #openttdcoop.devzone 16:16:50 <planetmaker> :-) Town name newgrf are the hit of the season it seems 16:17:23 <frosch123> considering the simplicity of the nml code of it, i guess it is a nml bug 16:20:41 <Ammler> hmm, portuguese names is a very small list 16:20:47 <Ammler> no splitting needed 16:21:13 <Brot6> firs: update from r1365 to r1366 done - http://bundles.openttdcoop.org/firs/nightlies/r1366 16:22:29 <Brot6> nml: update from r777 to r785 done - http://bundles.openttdcoop.org/nml/nightlies/r785 16:22:56 <Brot6> ogfx-trees: update from r18 to r21 done (3 errors) - http://bundles.openttdcoop.org/ogfx-trees/nightlies/r21 16:23:10 <Alberth> first some food 16:23:41 <Brot6> swisstowns: update from r14 to r18 done - http://bundles.openttdcoop.org/swisstowns/nightlies/r18 16:23:45 <Brot6> Following repos didn't need a nightlies update: 2cctrainset (r613), 32bpp-extra (r39), airportsplus (r62), basecosts (r20), belarusiantowns (r7), comic-houses (r71), fish (r390), frenchtowns (r4), grfcodec (r253), heqs (r372), metrotrackset (r56), newgrf_makefile (r190), nforenum (r502), nutracks (r115), ogfx-test (r529), ogfxplus (r42), opengfx (r539), openmsx (r97), opensfx (r97), snowlinemod (r42), swedishrails (r181), 16:23:46 <Brot6> transrapidtrackset (r15), ttdviewer (r25), ttrs (r20), worldairlinersset (r663) 16:24:01 <planetmaker> http://bundles.openttdcoop.org/ogfx-trees/nightlies/r21/log/ <-- Ammler what happens for you, if you click on the nfo file? 16:25:07 <Rubidium> you get nfo version woopsie? 16:25:33 <Ammler> planetmaker: might need to add + to the rewrite 16:25:36 <Ammler> hmm 16:25:45 <planetmaker> even replacing the + by %2B doesn't work 16:26:11 <Ammler> yeah, % might not be accepted either 16:26:59 <Ammler> hmm 16:27:37 <Ammler> (.*) <-- . is everything, isn't? 16:27:59 <Ammler> RewriteRule (.*) http://bundles.openttdcoop.org/download.php?file= [L] 16:28:15 <Ammler> but I disable rewrite for nfo 16:28:22 <Ammler> we don't need to count those 16:28:46 <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: airportsplus (Diffsize: 1), belarusiantowns (3 errors) (Diffsize: 22), frenchtowns (4 errors) (Diffsize: 10), ogfxplus (Diffsize: 7), swedishrails (Diffsize: 6) 16:30:06 <Ammler> oh, it's not just the nfo 16:33:39 <planetmaker> it doesn't like '+' 16:34:00 <planetmaker> hm... I know again why I didn't like the name with '+' in the first place 16:34:15 <Ammler> [Fri Sep 17 18:24:28 2010] [error] [client 134.169.28.42] File does not exist: /home/openttd/public_html/ogfx-trees/nightlies/r21/log/opengfx\+trees.nfo 16:34:37 <Ammler> might be a bug of the php script 16:34:42 <planetmaker> hm 16:34:59 <planetmaker> but... they're displayed by the html? How do they get there then? 16:35:07 <Ammler> ? 16:35:25 <planetmaker> it's a simple directory listing, isn't it? 16:35:30 <Ammler> if it redirects to root, the error is at download.php 16:35:43 <planetmaker> ah. That one .-) 16:38:03 <Ammler> php does convert + to " " 16:39:06 <planetmaker> he 16:39:52 <planetmaker> urlencode the thing first, maybe 16:42:21 <Hirundo> Alberth: Would you be interested to take a look at http://bugs.openttd.org/task/4124 ? 16:42:55 <planetmaker> :-) 16:44:16 <Hirundo> hmm... perhaps I should have used <advertisement> tags 17:13:16 <andythenorth> #987 17:13:16 <Brot6> andythenorth: #987 is http://dev.openttdcoop.org/issues/show/987 "Swedish Rails - Feature #987: Improved snowy TTD track sprites - #openttdcoop Development Zone" 17:13:20 <andythenorth> #1010 17:13:20 <Brot6> andythenorth: #1010 is http://dev.openttdcoop.org/issues/show/1010 "FIRS Industry Replacement Set - Feature #1010: Clustering for mines - #openttdcoop Development Zone" 17:27:32 <Yexo> how to get the revision number of a hg repo? 17:27:52 <Yexo> without a + appended to it, so "hg id -n" doesn't do what I want 17:28:29 <Hirundo> do hg id -n, then replace '+ 17:28:37 <Hirundo> ' with '' 17:29:39 <planetmaker> hg id -n | cut -d+ -f1 17:29:45 <planetmaker> hg id -n | cut -d\+ -f1 17:29:47 <planetmaker> maybe 17:30:35 <planetmaker> Yexo: the makefile has a line which tells :-) 17:35:53 <frosch123> you can also use hg parents with some --template 17:36:02 <planetmaker> true 17:37:01 <Alberth> Hirundo: doesn't look like I can say anything useful about it 17:37:29 <planetmaker> But frosch123 can maybe ;-) 17:37:55 <planetmaker> [18:42] <Hirundo> Alberth: Would you be interested to take a look at http://bugs.openttd.org/task/4124 ? <-- that line is referenced ;-) 17:38:16 <frosch123> already looked at it somewhen this week 17:38:21 <planetmaker> :-) 17:38:36 <planetmaker> and quickly looked away again? :-P 17:38:41 <frosch123> andy should attach a testgrf for nforenum+grfcodec+ottd 17:38:52 <frosch123> the diffs looked fine 17:39:01 <planetmaker> andythenorth: ^ 17:43:54 *** fanioz has joined #openttdcoop.devzone 17:58:17 <Alberth> Hmm, 'make.sh' of swisstowns breaks on some weird 7za command 17:59:54 <planetmaker> that's zip 18:00:05 <planetmaker> rather 7zip 18:00:16 <planetmaker> as such it fails also here 18:00:41 * frosch123 has a 7za 18:01:17 <Ammler> planetmaker: I fixed teh + issue with not redirecting urls with + 18:01:23 <Ammler> so the trees don't have stats 18:01:36 <planetmaker> ok 18:01:37 <Ammler> feel free to commit a patch to fix that :-P 18:01:41 <planetmaker> :-P 18:01:46 <planetmaker> I have no clue about php 18:02:04 <Ammler> hmm, could also be mod_rewrite thing 18:02:31 <Brot6> 32bpp-ez-patches: update from r20817 to r20823 done - http://bundles.openttdcoop.org/32bpp-ez-patches/testing/r20823 18:04:27 <Brot6> AdmiralAI - Revision 64:30ab5bc5d7db: Change: version number now contains the hg revision. Makefi... (yexo) @ http://dev.openttdcoop.org/projects/ai-admiralai/repository/revisions/30ab5bc5d7db 18:04:47 <Yexo> Ammler: what do I need to do to enable a nightly build? 18:05:29 <Ammler> for ai? 18:05:49 <Yexo> yes 18:05:57 <Ammler> you like to use makefile? 18:06:12 <Yexo> that seems easiest as it's already in place 18:07:01 <planetmaker> oh. AdmiralAI migrated, too? :-) 18:07:10 <Yexo> might as well :) 18:07:17 <Ammler> in your case, I wonder, what is easiest for ai in general 18:07:35 <Ammler> as you need mingw just for making a tar 18:08:05 <planetmaker> Ammler: yes, but 'make' is the standard way to create something from source 18:08:06 <Yexo> but you don't need a tar for development 18:08:41 <Yexo> creating a proper tar on windows without mingw/cygwin is difficult anyway 18:08:58 <planetmaker> totalcommander helps there :-) 18:09:14 <planetmaker> the single most important windows application for me :-) 18:09:34 <Ammler> yexo, yes, but it is quite easy with bash 18:09:45 <Yexo> Ammler: windows users don't have bash 18:09:53 <Yexo> and when they do, they have cygwin/mingw so they have make too 18:10:12 <Ammler> yes, I mean, we could make the bundle without having make, thats all 18:10:53 <planetmaker> Ammler: *could*. But... why have custom calls when you can use the same thing for an ai as for newgrf? 18:11:58 <Ammler> planetmaker: I do not care about us, we can do all, I just think about if we should make make a requirement for just taring 18:12:17 <Brot6> clientpatches: update from r20817 to r20823 done - http://bundles.openttdcoop.org/clientpatches/testing/r20823 18:12:42 <Ammler> for example ai-trans doesn't have a Makefile 18:12:51 <planetmaker> nor a bash file 18:12:55 <Ammler> no need 18:13:10 <Ammler> we would do that with the spec 18:13:24 <Ammler> that is all :-) 18:13:51 <planetmaker> with the effect that the CF can bundle it, but no person who downloads it ;-) 18:13:55 <Yexo> ai-trains has a release.sh script that creates a tar 18:14:34 <Yexo> Ammler: planetmaker has a very good point there, I'd like to still be able to manually create a tar without too much work 18:15:04 <Ammler> Yexo: no need to remove the make 18:15:28 <Ammler> I just meant, we might not depend the build script upon it 18:15:31 <planetmaker> the build process should be contained in the repo. The 'specs' are just that it can be packed to the individual format 18:15:32 <Yexo> but if we don't remove the makefile we have two seperate systems that do exactly the same 18:15:48 <Ammler> yes :-( 18:16:07 <planetmaker> why are you so much against using the well-established 'make' for building things? 18:16:45 <Ammler> I am not 18:16:49 <Yexo> oh, the makefile currently creates "AdmiralAI-VERSION.tar", where VERSION is only the major version. That is fine for a release, but not for a nightly download as the version doesn't change every day 18:17:30 <Ammler> that doesn't matter, the VERSION there isn't used from the publisher 18:17:48 <Ammler> publisher uses either tip or tag 18:18:05 <Ammler> (not tip, head of default) 18:18:12 <Yexo> ok 18:18:29 <Ammler> well, I create a default type for ai with make 18:19:17 <Ammler> echo "ai" > .devzone/build/type 18:19:20 <Ammler> and 18:19:50 <Ammler> touch .devzone/build/nightlies/enable 18:19:59 <Ammler> and maybe the same for releases and push 18:20:15 <Ammler> also what files should be published? 18:20:15 <Alberth> What does this nforenum warning mean? //!!Warning (130): Offset 5: 7 bits are required, but only 01 were allocated. 18:21:00 <Rubidium> More options are available that the allocated bits can randomize between. 18:21:01 <Alberth> hmm, 7 bits for the random number generator perhaps? 18:21:03 <Rubidium> Reduce the probabilities or allocate more random bits. 18:22:41 <Alberth> probability reduction is not possible, they are all 1 already :) 18:22:46 <Alberth> Thanks Rubidium 18:23:16 <Rubidium> next time, nforenum's docs/sanity(.en).txt 18:23:30 <Alberth> ie, the random bits allocation is messed up :( 18:24:02 <Brot6> serverpatches: update from h8cd9642d to h6d709b4c done (2 errors) - http://bundles.openttdcoop.org/serverpatches/testing/h6d709b4c 18:24:39 <Ammler> Yexo: should it also zip the tar? 18:24:52 <planetmaker> Ammler: for download from bundles: yes 18:25:08 <Yexo> not sure, there is not much reason to zip it 18:25:10 <Ammler> does the makefile do that? 18:25:26 <Yexo> no, it doesn't 18:25:28 <Ammler> then we keep the tar 18:25:35 <planetmaker> depends what you want. bundle_tar, bundle_zip, ... 18:25:52 <Yexo> planetmaker: the tar can be directly read by openttd and contains everything 18:25:58 <planetmaker> bundle creating just the tar is the best choice for AI, though 18:26:02 <Yexo> the only reason to zip that tar would be to compress it 18:26:11 <planetmaker> Yexo: yes, but offering an unzipped tar for download? 18:26:30 <Yexo> why not? user downloads it to the openttd/ai/ directory and it works directly 18:26:34 <planetmaker> That's unusual :-) 18:26:36 <Yexo> no extra steps needed to unzip etc. 18:26:50 <planetmaker> and increases bandwidth. Not ours, but those of people downloading 18:27:03 <planetmaker> not everyone has a 16Mbit downstream 18:27:06 <planetmaker> Ask roboboy 18:27:19 <Yexo> true, but the last admiralai release tar was 400kb 18:27:38 <Yexo> gzipped it would be 75kb 18:27:57 <Ammler> Yexo: the type is made 18:28:08 <Ammler> push the .devzone files :-) 18:28:27 * Rubidium coughs and... proposes enabling gzip (in nginx) for downloading tars 18:28:29 <planetmaker> -rw-r--r-- 1 ingo staff 73313 17 Sep 20:28 test.zip 18:28:31 <planetmaker> -rw-r--r-- 1 ingo staff 399360 15 Aug 14:10 AdmiralAI-25.tar 18:28:48 <planetmaker> where test.zip is your AI zip'ed 18:28:59 <planetmaker> yes 18:29:08 <Ammler> hmm, yes, I could enable that 18:29:19 <Ammler> can I? 18:29:21 <Rubidium> that way you get the benefit of compression for bandwidth and no compression at the end 18:29:22 <planetmaker> Rubidium: that even works transparently? 18:29:30 <planetmaker> nice :-) 18:29:31 <Brot6> AdmiralAI - Revision 65:5a007e8986c9: Feature: enable nightlies (yexo) @ http://dev.openttdcoop.org/projects/ai-admiralai/repository/revisions/5a007e8986c9 18:30:13 <Rubidium> planetmaker: well, how big does your browser say OpenTTD's frontpage is? 18:30:22 <Rubidium> mine says 3.51 KB 18:30:29 <Rubidium> wget says it's 12 18:30:56 <Ammler> Yexo: why ai-admiralai? 18:31:07 <Ammler> ai twice 18:31:18 <Rubidium> to cancel out the noai 18:31:19 <planetmaker> nice, Rubidium :-) 18:31:30 <Yexo> "ai-" as prefix because it's an ai project (copied from noai.openttd.org), and "admiralai" because that's the complete name 18:31:35 <planetmaker> noai-ai-admiral-ai? 18:31:42 <Ammler> :-D 18:32:17 <Ammler> oh :-( 18:32:46 <Ammler> ah, stupid me 18:32:54 <Ammler> what is the target? 18:32:55 <Brot6> AdmiralAI - Bug #1506 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/1506 18:33:02 <Ammler> make bundle_tar ? 18:33:27 <Yexo> just make bundle 18:34:07 <Ammler> bundle should make a dir and copy the needed files into it 18:34:14 <Brot6> AdmiralAI - Bug #1506 (Rejected): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/1506 18:34:14 <Brot6> AdmiralAI - Bug #1506 (Rejected): DevZone compile failed (yexo) @ http://dev.openttdcoop.org/issues/1506#change-3956 18:34:23 <Ammler> I would like bundle_tar or tar 18:34:26 <Yexo> mhh, makefile updates info.nut now, but info.nut is part of the repo so hg shows it as modified every time 18:34:27 <Ammler> don't you agree? 18:35:04 <Ammler> does that matter? 18:35:12 <Yexo> changed 18:35:57 <Ammler> bundle_tar? 18:36:09 <Yexo> yes 18:36:36 <Ammler> push :-) 18:36:36 <Brot6> AdmiralAI - Revision 66:86d02e9223fe: Change: rename makefile target from bundle to bundle_tar (yexo) @ http://dev.openttdcoop.org/projects/ai-admiralai/repository/revisions/86d02e9223fe 18:36:39 <Ammler> ah :-P 18:36:57 <Yexo> Brot6: can be slow sometimes 18:37:00 <Brot6> ai-admiralai: update from to r66 done - http://bundles.openttdcoop.org/ai-admiralai/nightlies/r66 18:37:36 <Yexo> Ammler: the next nightly will have exactly the same filename 18:37:43 <Yexo> also AdmiralAI-26.tar 18:37:52 <Yexo> is that a problem or in this case actually "good" behavior? 18:38:33 <Ammler> up to you, finger does use the rev 18:38:44 <Ammler> and for releases the tag 18:39:14 <Ammler> hmm, the make has no output? 18:39:27 <Yexo> nope 18:39:31 <Ammler> then we don't need a build log :-) 18:39:56 <Ammler> any sanity check , we could run? 18:40:11 <Ammler> ailint :-) 18:44:59 <Brot6> #openttdcoop - Revision 126:d06338fa6259: [Compiler] Bulkupdate, as always :-) (Ammler) @ http://dev.openttdcoop.org/projects/home/repository/revisions/d06338fa6259 18:47:25 <Brot6> #openttdcoop - Revision 127:b437db173cee: [Compiler] Feature: new build type ai (Ammler) @ http://dev.openttdcoop.org/projects/home/repository/revisions/b437db173cee 18:47:42 <Ammler> if someone has another script or something else, he could cp the "default spec" to .devzone/build and modify 18:48:55 <Ammler> for example repalce "make bundle_tar" with ./release.sh 18:49:06 <fanioz> :D 18:52:13 <Ammler> Yexo: if you will release again, you call the tag v27, right? 18:52:24 <Yexo> yes 18:52:45 <Ammler> got it :-) 18:53:18 <Ammler> nobody uses rev as version? 18:59:28 <Yexo> some do, maybe I should switch to that too 19:12:55 <Brot6> Portuguese Town Names - Revision 0:399a0faf0f9f: Initial commit (Ammler) @ http://dev.openttdcoop.org/projects/portuguesetowns/repository/revisions/399a0faf0f9f 19:17:11 <Brot6> portuguesetowns: update from to r0 done - http://bundles.openttdcoop.org/portuguesetowns/push/r0 19:22:46 <Brot6> Portuguese Town Names - Feature Request #1505: Portuguese Town Names (Ammler) @ http://dev.openttdcoop.org/issues/1505#change-3957 19:38:49 <Brot6> Portuguese Town Names - Revision 1:32bc3ec6bf3d: Fix: {{MARKER}} -> {MARKER}, remove first "\" fr... (Ammler) @ http://dev.openttdcoop.org/projects/portuguesetowns/repository/revisions/32bc3ec6bf3d 19:38:49 <Brot6> Portuguese Town Names - Revision 2:7b89e611c624: Add .hgignore (Ammler) @ http://dev.openttdcoop.org/projects/portuguesetowns/repository/revisions/7b89e611c624 19:46:49 <Brot6> Portuguese Town Names - Revision 3:f721131fdd86: Fix: escape escape escapse... (Ammler) @ http://dev.openttdcoop.org/projects/portuguesetowns/repository/revisions/f721131fdd86 19:50:46 <Terkhen> Ammler: you managed to install PIL? 19:52:01 <Ammler> yes 19:52:16 <Ammler> you need to define the platform 19:52:23 <Ammler> something like compiler=mingw or so 19:54:00 <Terkhen> thanks :) 19:54:36 <Ammler> --compiler=mingw32 19:55:02 <Ammler> ply was no issue, right? 19:55:24 <Terkhen> I still haven't tested it, but the installer ran fine 19:56:01 <Terkhen> hmm... I get a lot of undefined references 19:56:41 <Ammler> I think, I have tested with ser and compared the md5sum 19:57:10 <Ammler> or not :-( 19:57:21 <Ammler> only with swisstowns, which has no images 19:58:10 <Ammler> running with ser now 19:58:22 <Terkhen> hmmm... I think it does not like python x86-64 19:58:32 <Terkhen> at least under windows 19:58:49 <Ammler> oh, I have i686 19:59:10 <andythenorth> evening 19:59:15 <Terkhen> let's see if the errors go away with x86 19:59:17 <Terkhen> hi andythenorth 19:59:18 <Ammler> hmm, the "cc" bug is still in the repo 19:59:28 <Terkhen> yes, it is still not fixed 19:59:45 <planetmaker> hm 19:59:50 <Ammler> make CC=gcc? 20:00:02 <Terkhen> defining CC should work 20:00:15 <Ammler> now I got the grep -o issue 20:00:41 <Ammler> planetmaker: how do you test which dep check to sue? 20:00:43 <Ammler> use* 20:00:54 <planetmaker> hg present -> mdep.py 20:01:00 <Ammler> hmm 20:02:49 <planetmaker> Terkhen: so you wang CC=gcc with mingw? 20:02:52 <planetmaker> always? 20:03:02 <Terkhen> no, that would not be a good solution 20:03:04 <planetmaker> hm... I guess I might have only fixed it in the newgrf-makefile 20:03:13 <Terkhen> it would fail to behave as expected 20:03:28 <Terkhen> if I redefine CC, it should use the value I defined 20:03:38 <planetmaker> that's what I think 20:04:26 <Ammler> installing nml doesn't work 20:04:31 <Ammler> it doesn't find nmlc 20:04:47 <Terkhen> Ammler: you need to add python\Scripts to PATH 20:04:58 <Terkhen> that's where I found nmlc 20:08:11 <Ammler> I got "Empty input file" 20:08:13 <planetmaker> Terkhen: now... I think there was an issue with the proposed CC patch :-) 20:08:16 <Ammler> is that from nml? 20:08:45 <Terkhen> I remember it failed in other OSes 20:08:47 <Terkhen> but not why 20:08:55 <Ammler> yes, nml 20:09:51 <Terkhen> http://pastebin.com/W21jv5RU <-- this should be enough anyways 20:10:03 <Ammler> [22:00] <planetmaker> hg present -> mdep.py <-- shouldn't you rather test for python? 20:10:24 <Terkhen> that code works as expected under mingw32, moving it into the mingw32 check ensures that it won't get called when it is not needed 20:10:32 <planetmaker> true 20:10:34 <Terkhen> I'm testing it right now under mingw32 20:11:16 <Ammler> how do I see, which dep check it uses? 20:12:12 <Terkhen> yeah, here that diff works 20:15:25 <planetmaker> Ammler: yes, I could test for python. I just do that implicitly so far. 20:15:44 <planetmaker> which... is dodgy. I was told that hg doesn't mean python on certain windows installations :-) 20:16:14 <Ammler> Terkhen: your wiki doesn't use lunac? 20:16:51 <Terkhen> mingw released their own installer a few days after I wrote that post 20:17:01 <Ammler> ah :-) 20:17:06 <Terkhen> I'm using it since it is easier to install perl, wget and stuff like that 20:17:20 <Ammler> yes, I liked to install wget :-P 20:18:34 <Terkhen> never CTRL+C their command line installer, though... it will get renamed to mingw-get~ :P 20:26:14 <planetmaker> I now have code for the dep check which uses gcc for the source files... 20:35:32 <Terkhen> I'm going to compile python from source, let's see if it is less messy that way 20:38:04 <Terkhen> http://bugs.python.org/issue9098 <--- or maybe I won't 20:38:06 <Webster> Title: Issue 9098: MSYS build fails with `S_IXGRP' undeclared - Python tracker (at bugs.python.org) 20:38:22 <Terkhen> I'm starting to think of moving to cygwin :P 20:43:04 <planetmaker> he 20:55:14 <Ammler> python works here fine 20:55:19 *** Alberth has left #openttdcoop.devzone 20:55:28 <Ammler> I have issues with other things 20:56:43 <frosch123> isn't it kind of weird to escape 00 in 0-terminated binary data using '\' :) 20:58:15 <planetmaker> hehe :-) 21:02:28 *** fanioz has quit IRC 21:11:13 <Terkhen> I managed to build PIL, but it is compiled without PNG support... this is a big no for NML, right? 21:12:02 <Ammler> yes 21:12:26 <Terkhen> thought so :) 21:12:42 <planetmaker> he :-) 21:12:49 <planetmaker> that's mostly useless 21:13:18 <planetmaker> all bigger NML projects use png files ;-) 21:13:27 <planetmaker> maybe airports use pcx (still) 21:14:46 <Yexo> no, I already converted that to png too 21:15:01 *** thgergo has quit IRC 21:15:12 <planetmaker> :-) 21:19:54 *** thgergo has joined #openttdcoop.devzone 21:28:04 <Brot6> Example NewGRF Project - Revision 191:06187e7de6a3: Change #1277: Modularize the dep check a bit ... (planetmaker) @ http://dev.openttdcoop.org/projects/newgrf-makefile/repository/revisions/06187e7de6a3 21:37:51 <planetmaker> I guess now it's really possible to skip the dep check 21:38:06 <planetmaker> even though it'll still tell that it does it ;-) 21:38:24 <planetmaker> it won't scan any files then anymore 21:39:17 <Brot6> Example NewGRF Project - Revision 192:73c92def7aa6: Change #1178: Remove a few unneeded ifdefs (planetmaker) @ http://dev.openttdcoop.org/projects/newgrf-makefile/repository/revisions/73c92def7aa6 21:47:39 <Brot6> Example NewGRF Project - Revision 193:8605b33400eb: Fix #1449: Define gcc for buggy MinGW (planetmaker) @ http://dev.openttdcoop.org/projects/newgrf-makefile/repository/revisions/8605b33400eb 21:47:40 <Brot6> Example NewGRF Project - Bug #1449 (Closed): Compiling under MinGW/MSYS (planetmaker) @ http://dev.openttdcoop.org/issues/1449#change-3958 21:47:58 <planetmaker> Terkhen: which newgrf(s) do you usally build and which could I ask you to just test-build with a diff? 21:48:17 <planetmaker> firs? 21:48:44 <Terkhen> firs, fish, heqs, 2cc, opengfx, opensfx, openmsx 21:49:03 <Terkhen> I only have tested opengfx 21:50:37 <planetmaker> http://pastebin.com/e1cup3E6 <-- that's the diff from opengfx, updating to the current makefile version 21:51:14 <planetmaker> you have the option, if you like, to use DEP_CHECK_TYPE=none|normal|mdep 21:51:30 <planetmaker> mdep is the default. But.. it's not perfect 21:52:26 <Terkhen> I'm currently reinstalling the whole thing; it might take a while until I can test it 21:52:32 <planetmaker> no rush 21:52:52 <planetmaker> I'm getting too tired anyway to do much ;-) 21:53:20 <Terkhen> :) 21:53:59 <planetmaker> hm... normal fails for me :S 21:54:59 <planetmaker> seems capital letters missing are a capital error :-P 22:04:12 *** ODM has quit IRC 22:13:17 <Brot6> FIRS Industry Replacement Set - Revision 1367:bba9e3c42d59: Feature: Blacksmith accepts Wood inst... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/bba9e3c42d59 22:13:17 <Brot6> FIRS Industry Replacement Set - Revision 1368:9e7d1aa85f66: Feature: Blacksmith renamed to Forge (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/9e7d1aa85f66 22:13:18 <Brot6> FIRS Industry Replacement Set - Revision 1369:7b7aa4f098db: Change: updated industry window text ... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/7b7aa4f098db 22:18:11 <Brot6> NFORenum - Revision 503:7e31ca96a8a7: Codechange: Use macros to construct most of _dat0. (frosch) @ http://dev.openttdcoop.org/projects/nforenum/repository/revisions/7e31ca96a8a7 22:30:17 <Brot6> Example NewGRF Project - Revision 194:d633813a1a43: Change: Add better regex testing capability o... (planetmaker) @ http://dev.openttdcoop.org/projects/newgrf-makefile/repository/revisions/d633813a1a43 22:34:57 <Brot6> Example NewGRF Project - Revision 195:71e8f6f2bc9a: Fix: Regex are regularily cause for bad expre... (planetmaker) @ http://dev.openttdcoop.org/projects/newgrf-makefile/repository/revisions/71e8f6f2bc9a 22:37:29 <planetmaker> http://pastebin.com/fAVV9RCy <-- update, Terkhen 22:37:37 <planetmaker> and now have all a good night 22:37:44 <Terkhen> good night planetmaker 22:52:16 <Brot6> Example NewGRF Project - Revision 196:34b647abe954: Fix: mdep check threw away all its effort, ov... (planetmaker) @ http://dev.openttdcoop.org/projects/newgrf-makefile/repository/revisions/34b647abe954 22:58:24 *** thgergo has quit IRC 23:08:06 <Terkhen> planetmaker: the diff file does not apply cleanly; there are a lot of "reversed or previously applied hunks" 23:47:05 *** KenjiE20 has quit IRC 23:58:05 <Ammler> Terkhen: do you have UTF-8 in your msys env? 23:58:40 <Ammler> if I make cat swisstowns.nml, I got iso-8859 or whatever output