Log for #openttdcoop.devzone on 17th September 2010:
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) @
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) @
07:07:35  <Brot6> NewGRF Meta Language - Feature #1031: support for houses (planetmaker) @
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) @
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>
07:50:40  <Webster> Title: Tables in HTML documents (at
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) @
08:32:52  <Brot6> NewGRF Meta Language - Revision 783:f0a99108991b: Doc: Add documentation for house properties (planetmaker) @
08:42:51  <Brot6> NewGRF Meta Language - Feature #1031: support for houses (planetmaker) @
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) @
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) @
09:00:50  <planetmaker> @calc 0.27/0.3
09:00:50  <Webster> planetmaker: 0.9
09:12:11  <planetmaker> <-- 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:
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>
09:38:22  <Webster> Title: Transport Tycoon Forums • View topic - [Patch] Virtual time (at
09:38:27  <Rubidium>
09:38:31  <Webster> Title: Transport Tycoon Forums • View topic - [Patch] Departure boards, 24h clock (+ binary) (at
09:38:40  <Rubidium>
09:38:41  <Webster> Title: Transport Tycoon Forums • View topic - [Patch] Improved Timetable Management [V2.31tr SVN15778] (at
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>
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> <-- 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) @
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) @
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) @
13:26:06  <Brot6> OpenGFX+ Trees - Revision 20:732ebc79a354: Removed tag 0.2.0 (Froix) @
13:26:06  <Brot6> OpenGFX+ Trees - Revision 21:384f4f6537f5: Feature: Added ability to disable any number of trees.... (Froix) @
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 -
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> <-- 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
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> <-- 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
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) @
14:32:49  <Brot6> #openttdcoop - Membership #1502 (Closed): Applying for project: AI-Trans (Ammler) @
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: <-- opengfx+ grf?
14:55:57  <Webster> Title: Transport Tycoon Forums • View topic - [OTTD] Big GUI (Double Sized GUI) [WIP] (at
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 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) @
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) @
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) @
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) @
16:04:11  <Brot6> Swiss Town Names - Revision 16:078a73d6ad5f: Feature: exit/abort if nml wasn't able to build the grf (Ammler) @
16:04:12  <Brot6> Swiss Town Names - Revision 17:38ba3997c8f0: Fix: grf{} requires version (Ammler) @
16:04:13  <Brot6> Swiss Town Names - Revision 18:85b3b623b30a: Change: use the internal split of nml (Ammler) @
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) @
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 -
16:22:29  <Brot6> nml: update from r777 to r785 done -
16:22:56  <Brot6> ogfx-trees: update from r18 to r21 done (3 errors) -
16:23:10  <Alberth> first some food
16:23:41  <Brot6> swisstowns: update from r14 to r18 done -
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> <-- 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 (.*) [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] 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 ?
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 "Swedish Rails - Feature #987: Improved snowy TTD track sprites - #openttdcoop Development Zone"
17:13:20  <andythenorth> #1010
17:13:20  <Brot6> andythenorth: #1010 is "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 ? <-- 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, '' 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 -
18:04:27  <Brot6> AdmiralAI - Revision 64:30ab5bc5d7db: Change: version number now contains the hg revision. Makefi... (yexo) @
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 -
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 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) -
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
18:28:31  <planetmaker> -rw-r--r--  1 ingo  staff  399360 15 Aug 14:10 AdmiralAI-25.tar
18:28:48  <planetmaker> where 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) @
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, 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) @
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) @
18:34:14  <Brot6> AdmiralAI - Bug #1506 (Rejected): DevZone compile failed (yexo) @
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) @
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 -
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) @
18:47:25  <Brot6> #openttdcoop - Revision 127:b437db173cee: [Compiler] Feature: new build type ai (Ammler) @
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 ./
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) @
19:17:11  <Brot6> portuguesetowns: update from  to r0 done -
19:22:46  <Brot6> Portuguese Town Names - Feature Request #1505: Portuguese Town Names (Ammler) @
19:38:49  <Brot6> Portuguese Town Names - Revision 1:32bc3ec6bf3d: Fix: {{MARKER}} -> {MARKER}, remove first "\" fr... (Ammler) @
19:38:49  <Brot6> Portuguese Town Names - Revision 2:7b89e611c624: Add .hgignore (Ammler) @
19:46:49  <Brot6> Portuguese Town Names - Revision 3:f721131fdd86: Fix: escape escape escapse... (Ammler) @
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 ->
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> <-- this should be enough anyways
20:10:03  <Ammler> [22:00] <planetmaker> hg present -> <-- 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> <--- or maybe I won't
20:38:06  <Webster> Title: Issue 9098: MSYS build fails with `S_IXGRP' undeclared - Python tracker (at
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) @
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) @
21:47:39  <Brot6> Example NewGRF Project - Revision 193:8605b33400eb: Fix #1449: Define gcc for buggy MinGW (planetmaker) @
21:47:40  <Brot6> Example NewGRF Project - Bug #1449 (Closed): Compiling under MinGW/MSYS (planetmaker) @
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> <-- 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) @
22:13:17  <Brot6> FIRS Industry Replacement Set - Revision 1368:9e7d1aa85f66: Feature: Blacksmith renamed to Forge (andythenorth) @
22:13:18  <Brot6> FIRS Industry Replacement Set - Revision 1369:7b7aa4f098db: Change: updated industry window text ... (andythenorth) @
22:18:11  <Brot6> NFORenum - Revision 503:7e31ca96a8a7: Codechange: Use macros to construct most of _dat0. (frosch) @
22:30:17  <Brot6> Example NewGRF Project - Revision 194:d633813a1a43: Change: Add better regex testing capability o... (planetmaker) @
22:34:57  <Brot6> Example NewGRF Project - Revision 195:71e8f6f2bc9a: Fix: Regex are regularily cause for bad expre... (planetmaker) @
22:37:29  <planetmaker> <-- 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) @
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

Powered by YARRSTE version: svn-trunk