Times are UTC Toggle Colours
01:21:51 *** KenjiE20 has quit IRC 02:08:08 *** XeryusTC2 has joined #openttdcoop.devzone 02:08:47 *** XeryusTC has quit IRC 02:57:00 *** Lakie has quit IRC 03:52:00 *** thgergo has quit IRC 05:24:23 <Brot6> 2cc train set - Bug #2216: Naming of engines (EmperorJake) @ http://dev.openttdcoop.org/issues/2216#change-5630 05:29:14 <Brot6> 2cc train set - Bug #2216: Naming of engines (EmperorJake) @ http://dev.openttdcoop.org/issues/2216#change-5631 05:33:27 <Brot6> Bundles Update: g6fcf912c 2011-02-01 cargodist (http://bundles.openttdcoop.org/cargodist) 05:35:21 <Brot6> 2cc train set - Bug #2216: Naming of engines (EmperorJake) @ http://dev.openttdcoop.org/issues/2216#change-5632 07:28:38 <Brot6> 2cc train set - Bug #2216: Naming of engines (Voyager1) @ http://dev.openttdcoop.org/issues/2216#change-5633 07:46:53 <Brot6> 2cc train set - Bug #2216: Naming of engines (EmperorJake) @ http://dev.openttdcoop.org/issues/2216#change-5634 08:07:34 *** ODM has joined #openttdcoop.devzone 08:08:58 <Brot6> 2cc train set - Bug #2216: Naming of engines (EmperorJake) @ http://dev.openttdcoop.org/issues/2216#change-5635 08:19:05 <Brot6> 2cc train set - Bug #2228: r727 (EmperorJake) @ http://dev.openttdcoop.org/issues/2228#change-5637 08:28:08 <Brot6> 2cc train set - Feature #2157: China Railways HXD3 (EmperorJake) @ http://dev.openttdcoop.org/issues/2157#change-5638 08:37:08 <Brot6> 2cc train set - Bug #2216: Naming of engines (EmperorJake) @ http://dev.openttdcoop.org/issues/2216#change-5639 09:32:14 <Brot6> 2cc train set - Bug #2216: Naming of engines (Voyager1) @ http://dev.openttdcoop.org/issues/2216#change-5640 09:34:21 <Brot6> 2cc train set - Bug #2216: Naming of engines (Voyager1) @ http://dev.openttdcoop.org/issues/2216#change-5640 10:54:21 <Brot6> 2cc train set - Bug #2216: Naming of engines (EmperorJake) @ http://dev.openttdcoop.org/issues/2216#change-5642 10:58:06 <Brot6> 2cc train set - Bug #2216: Naming of engines (EmperorJake) @ http://dev.openttdcoop.org/issues/2216#change-5642 11:29:33 *** KenjiE20 has joined #openttdcoop.devzone 11:30:38 <Brot6> 2cc train set - Bug #2216: Naming of engines (Voyager1) @ http://dev.openttdcoop.org/issues/2216#change-5643 11:56:22 *** ODM has quit IRC 12:12:47 *** DayDreamer has joined #openttdcoop.devzone 12:45:26 <Brot6> 2cc train set - Feature #2213: NS DH1 (Purno) @ http://dev.openttdcoop.org/issues/2213#change-5645 12:57:56 *** DanMacK has joined #openttdcoop.devzone 12:58:00 <DanMacK> Hey all 13:00:51 <Brot6> 2cc train set - Support #2211: Feedback from the community / playerbase (Purno) @ http://dev.openttdcoop.org/issues/2211#change-5646 13:07:38 <Brot6> 2cc train set - Support #2211: Feedback from the community / playerbase (planetmaker) @ http://dev.openttdcoop.org/issues/2211#change-5647 13:07:48 <planetmaker> hi DanMacK :-) 13:07:56 <planetmaker> you're always up very early recently ;-) 13:11:58 <DanMacK> Yeah... start earlier at work 13:18:20 <planetmaker> Yexo, would it be possible and sensible for NML to get a command 'basesprites' similar to 'replace' which does the same except writing the actionA - thus allowing to write stuff for a base set? 13:18:31 <planetmaker> it'd be tremendously useful ;-) 13:19:19 <planetmaker> I'd like to start to employ something like that for OpenGFX as it eases work quite a bit... 13:19:30 <planetmaker> but so far output always needs post-editing which is not optimal 13:29:41 *** thgergo has joined #openttdcoop.devzone 15:10:42 *** DayDreamer has quit IRC 15:11:54 *** ODM has joined #openttdcoop.devzone 15:11:58 *** ODM has quit IRC 15:30:22 <dihedral> hey ho 15:35:56 <Yexo> planetmaker: makes sense 15:36:12 <Yexo> nml still misses support for recolor sprites though 15:45:27 <planetmaker> I don't care for that so far. 15:45:57 <planetmaker> What I need now is using NML to generate some NFO output which I can use 15:46:08 <DJNekkid> doea anyone know where i can find a palette-file with the 8bbp palette? 15:46:20 <DJNekkid> im so sick of copy/paste into a file that i know works :) 15:46:36 <planetmaker> That way I can somewhat start the transition without actually requiring so far NML as a tool; I'd just add both, NML and NFO output generated by NML to the source 15:46:51 <planetmaker> DJNekkid, DevZone? 15:48:39 <planetmaker> Yexo, could I ask you the favour to actually add that to NML if it's not much hassle? I stared at it this morning / last evening but not quite got it working... 15:50:02 <planetmaker> http://dev.openttdcoop.org/projects/home/documents <-- DJNekkid 15:50:18 <Yexo> sure, np 15:52:22 <DJNekkid> i was looking for a .pal file 15:53:08 <planetmaker> Well. There are photoshop and gimp palettes. As you don't tell what palette file you need... 15:53:17 <planetmaker> but I know of no others. 15:53:36 <DJNekkid> i know i saw one not too many days ago... arg! 15:56:26 <Ammler> you are using paint shop pro or which app does use .pal? 15:57:02 <DJNekkid> i.mage 15:57:20 <planetmaker> if you obtain it: make sure you upload it to the same place I just linked you 15:59:24 <DJNekkid> i'll just install gimp :P 16:07:49 <DJNekkid> oh jesus christ 16:07:54 <DJNekkid> an app in norwegian! 16:07:59 <DJNekkid> i HATE norwegian software! 16:08:07 *** Lakie has joined #openttdcoop.devzone 16:11:53 <DanMacK> Hey Lakie 16:15:48 <Lakie> Hi DanMacK 16:16:36 <Brot6> Nutracks - Revision 176:c7a785ac7a6a: Change: New High Speed Tracks (230kmh) gfx (DJNekkid) @ http://dev.openttdcoop.org/projects/nutracks/repository/revisions/c7a785ac7a6a 16:20:58 <Brot6> NewGRF Meta Language - Revision 1140:196e4b0807af: Feature: base_sprites block, works the same as... (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/196e4b0807af 16:21:32 <Brot6> NewGRF Meta Language - Revision 1141:1d93229c097d: Fix: don't forget to hg add new files (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/1d93229c097d 16:21:33 <Yexo> planetmaker: NML syntax: base_sprite [block_name]([default_file]) { ..real sprites.. } 16:21:48 <Yexo> so same as replace-block but without the spritenumber 16:24:15 <planetmaker> Well. Sprite number might be useful, too 16:24:39 <planetmaker> Because for base sets the sprite numbers have to be exact the chosen one 16:25:01 <planetmaker> They might only make sense for illustration purposes or for writing NFO, though 16:25:25 <planetmaker> I'd like nfo to show the proper sprite number :-) 16:25:25 <DanMacK> Some people have really odd issues with this game... 16:25:45 * DanMacK quietly looks in #openttd 16:26:41 <Terkhen> and they defend their solutions fiercely :) 16:28:35 <Brot6> 2cc train set - Support #2211: Feedback from the community / playerbase (DJNekkid) @ http://dev.openttdcoop.org/issues/2211#change-5648 16:29:31 <Brot6> 2cc train set - Feature #2213: NS DH1 (Voyager1) @ http://dev.openttdcoop.org/issues/2213#change-5649 16:30:37 <Brot6> 2cc train set - Support #2211: Feedback from the community / playerbase (V453000) @ http://dev.openttdcoop.org/issues/2211#change-5650 16:32:44 <Brot6> 2cc train set - Feature #2213: NS DH1 (Voyager1) @ http://dev.openttdcoop.org/issues/2213#change-5652 16:35:13 <Yexo> planetmaker: that'd make 2 optional arguments (file and sprite number) without a way to distinguish which one is given 16:37:01 <planetmaker> then I'd keep the sprite number actually necessary 16:37:15 <planetmaker> It would (later) possibly allow to check for sanity 16:37:35 <Brot6> 2cc train set - Support #2211: Feedback from the community / playerbase (Voyager1) @ http://dev.openttdcoop.org/issues/2211#change-5653 16:38:00 <Yexo> I'm not sure I agree with that, the written sprite number is consecutive 16:38:04 <planetmaker> Let's say when we define a grf to be a base file, the sprite(s) xy really has to be starting with the sprite xy which is written to the file 16:38:19 <Yexo> if anything I'd rather have a commandline argument that prints sets the starting spriteid 16:38:22 <planetmaker> yes. But for a base set every sprite has to be at an exact number 16:39:13 <planetmaker> Well. I imagine that NML could maybe later feature an extension to the grf block which tells it to be a base set grf 16:39:28 <Yexo> a base set doesn't need a grf block 16:39:35 <planetmaker> Well, yes 16:42:39 <planetmaker> hm, how can the file actually be optional for real sprites? 16:42:50 <Yexo> filename can be part of the real sprite 16:43:17 <planetmaker> not must be? 16:45:06 <Yexo> http://pastebin.com/J8BLjEd8 both blocks result in the same output 16:45:58 <planetmaker> ah, I forgot the 2nd syntax. Thanks for reminding me :-) 16:46:14 <Brot6> 2cc train set - Support #2211: Feedback from the community / playerbase (V453000) @ http://dev.openttdcoop.org/issues/2211#change-5654 16:47:09 <planetmaker> I still think that base sprites only make sense with a fixed number. It's not a variable which can be freely chosen 16:47:54 <planetmaker> So forcing it is a kind of implicit debugging mechanism, if numbers are not consecutive 16:48:10 *** frosch123 has joined #openttdcoop.devzone 16:48:34 <planetmaker> quak :-) - maybe frosch has an opinion on that, or Ammler ;-) 16:49:07 <Yexo> planetmaker: but numbers have to be consecutive 16:49:14 <frosch123> moin 16:49:19 <Ammler> I wonder, how else you identify a base sprite? 16:49:24 <Yexo> the actual number in the nfo is never written to the grf file, it's just to make errors more readable 16:49:37 <Yexo> the order of sprites in the grf file is how they're identified 16:49:58 <Yexo> ie first sprite is 1, second sprite is 2. What the numbers in the nfo file said is not relevant 16:51:12 <Ammler> planetmaker: can you make a example, how it looks now and how it should look 16:51:21 <Ammler> I don't get where you miss the number 16:51:51 <planetmaker> the question is: should a command in NML for base set sprites require the sprite number to be given or not? 16:52:03 <Ammler> how else? 16:52:15 <Yexo> http://pastebin.com/0JXXbLPm <- Ammler 16:52:23 <planetmaker> Yexo, the resulting sprites have to be consecutive. I could with one base_sprites command probably write 8 or so (e.g. a vehicle) - like with actionA 16:52:38 <frosch123> hmm, i read the logs, but i don't get the point... :) 16:52:47 <frosch123> planetmaker: do you want to code base graphics in nml? 16:52:53 <planetmaker> yes 16:53:11 <Yexo> planetmaker: even if you could specify the sprite number, nml can't do anything useful with it 16:53:11 <Brot6> 2cc train set - Support #2211: Feedback from the community / playerbase (DJNekkid) @ http://dev.openttdcoop.org/issues/2211#change-5655 16:53:17 <planetmaker> I don't want to require it (now). But I want to make my live easier 16:53:22 <Yexo> as such I'm against including it, it's askig the user for more information than needed 16:53:27 <frosch123> Yexo: maybe an assertion? 16:53:34 <Yexo> that's the only use 16:53:40 <planetmaker> yes, quite a good one 16:53:48 <Yexo> but since the filename is already an optional parameter, we would have 2 optional parameters 16:53:54 <planetmaker> messing up sprite numbers in a base grf otherwise leads to assertions in OpenTTD 16:53:59 <Yexo> I don't see a good way how to handle that 16:54:06 <Yexo> unless we only allow the sprite number if a filename is given 16:54:16 <frosch123> but nevertheless, i don't consider nml suited for base graphics 16:54:23 <frosch123> is it only about sprite templates? 16:54:35 <planetmaker> frosch123, it is. Yes, it's about sprite templates. VERY useful 16:54:40 <planetmaker> with x and y offsets etc. 16:55:02 <planetmaker> the cpp templates are... bulky 16:56:37 <frosch123> well, i guess it makes no sense to combine base graphics with any other nml elements, e.g. there must be no "grf {}" tag, nor may nml write sprite 0. so basically the input needs quite different syntax 16:57:06 <Yexo> sprite 0 is only written if there is a grf-block 16:57:16 <planetmaker> frosch123, for now I'll be happy by a simple list of real sprites. And ...^ 16:57:24 <frosch123> oh, so the grf block is already optional? 16:57:28 <planetmaker> yes 16:57:34 <planetmaker> always was ;-) 16:57:50 <Yexo> you won't get an action8 without one 16:58:15 <Yexo> it's useful for basesets but also to generate nfo files from nml to include in an nfo-project 16:58:17 <Ammler> Yexo: but you need it for a kind of offset, don't you? 16:58:25 <frosch123> and no a14 either, i guess 16:58:36 <Yexo> A14 is only written when needed 16:58:44 <Yexo> since all information is in the grf-block, it won't be written 16:59:01 <frosch123> you don't set the palette type in the grf block 16:59:08 <Yexo> hmm, good point 16:59:10 <Yexo> let me check 16:59:34 <Ammler> I don't see, how you will make the nfo without the sprite number 17:00:28 <Yexo> NML: base_sprites my_replace_name("8bpp_graph_sprite.png") { [-8, -8] } 17:00:36 <Yexo> generated nfo: 0 8bpp_graph_sprite.png 0 0 01 20 20 -8 -8 17:00:51 <Ammler> and where is that "0" from? 17:00:53 <Yexo> no need for a sprite number :) 17:00:59 <Yexo> consecutively numbered 17:01:08 <Yexo> first sprite is 0, second one is 1, etc. 17:01:15 <Yexo> it doesn't matter anyway 17:01:17 <frosch123> what kind of block is "base_sprites" ? 17:01:31 <Yexo> just "real sprites", without any other actions 17:01:41 <Yexo> basically a replace-block without writing the actionA 17:02:00 <frosch123> so something which only makes sense in base graphics? i.e. it is not nested in some action1/5/a/12 ? 17:02:03 <Yexo> a14 is only written when a grf-block exists 17:02:10 <Yexo> correct 17:02:32 <Yexo> actionA = replace-block (almost the same syntax but requires a sprite number) 17:02:41 <frosch123> but then you could add the spritenumber as optional parameter, which behaves as assertion, right? 17:02:43 <Yexo> action5 is replacenew-block, same as replace-block 17:02:54 <Yexo> yes, I'm trying to do that now 17:03:07 <Yexo> problem is: the filename is already optional, so we'll have 2 optional parameters 17:03:20 <Yexo> result: sprite_number is only allowed when you also give a filename 17:04:07 <frosch123> what does it do without a filename? uses the last one? 17:04:29 <Yexo> the sprite definition will need to have a filename in that case 17:05:06 <Yexo> http://pastebin.com/J8BLjEd8 like this 17:05:27 <frosch123> oh 17:06:49 <frosch123> alternatively there could be a different block, which just acts as assertion. "base_sprite_number(123);" or so 17:07:17 <frosch123> i have no idea whether there is any block without {} though :) 17:07:46 <Yexo> param[3] = 4; <- "block" without {} 17:08:19 <Yexo> I've thought about that, but due to the processing order in nml that will be a lot more difficult 17:08:55 <Brot6> nml: update from r1139 to r1141 done - http://bundles.openttdcoop.org/nml/nightlies/r1141 17:09:11 <frosch123> well, i am neither developer nor user of that feature :) 17:09:34 <frosch123> but i can assist in forcing pm to like it :p 17:10:11 <Yexo> :p 17:12:13 <planetmaker> he...! ;-) 17:12:39 <planetmaker> Well, yes, I understand that a sprite number is not needed. 17:13:20 <planetmaker> But it is a very good sanity check. But yes, maybe the suggestion of frosch to force for consecutive sprites starting at a given number that syntax is ok for me, too 17:16:11 <Yexo> what should be done if the given sprite number doesn't match the output number? 17:16:20 <Yexo> currently it prints an error message 17:18:40 <Brot6> nutracks: update from r172 to r176 done - http://bundles.openttdcoop.org/nutracks/nightlies/r176 17:18:48 <Brot6> Following repos didn't need a nightlies update: 2cctrainset (r732), 32bpp-extra (r39), ai-admiralai (r75), ai-aroai (r11), ailib-common (r21), ailib-direction (r17), ailib-list (r32), ailib-string (r29), ailib-tile (r16), airportsplus (r70), basecosts (r22), belarusiantowns (r8), bros (r45), comic-houses (r71), firs (r1658), fish (r567), frenchtowns (r6), grfcodec (r821), heqs (r572), indonesiantowns (r41), manindu (r6), metrotrackset 17:18:48 <Brot6> (r56), narvs (r5), newgrf_makefile (r254), nml (r1141), ogfx-industries (r3), ogfx-landscape (r22), ogfx-rv (r78), ogfx-trains (r201), ogfx-trees (r42), opengfx (r593), openmsx (r97), opensfx (r97), smts (r19), snowlinemod (r45), spanishtowns (r10), swedishrails (r193), swisstowns (r22), transrapidtrackset (r15), ttdviewer (r26), ttrs (r24), worldairlinersset (r671) 17:19:28 <planetmaker> that's just fine, nothing else needs to be done. Not sure whether it should be fatal error, though. 17:19:46 <frosch123> it does not make sense to have holes in the middle, but if you want to concat multiple files it might make sense to not start at 0 17:20:07 <frosch123> i.e. what about mapgen sprites or similiar surprises? 17:20:18 <frosch123> hmm, though they were kind of images afaik 17:20:26 <Yexo> mapgen sprites are some sort of images 17:20:55 <planetmaker> they are 17:21:25 <planetmaker> hm. Possibly a better name right now would be base_graphics(...) than base_sprite 17:21:33 <planetmaker> As the latter could also be a recolour sprite 17:21:34 <Brot6> ogfx-rv: rebuild of r78 done (1 errors) (Diffsize: 1) (DiffDiffsize: 5) - http://bundles.openttdcoop.org/ogfx-rv/nightlies/r78/log 17:21:34 <Yexo> not starting at 0 is imo a different feature request (which indeed makes sense if you compile some file separately) but that needs a commandline-argument 17:21:41 <Yexo> or a different syntax at least 17:21:47 <Brot6> NewGRF Meta Language - Revision 1142:c4e1c301cb5e: Change: add optional sprite_num parameter to b... (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/c4e1c301cb5e 17:22:42 <Brot6> NewGRF Meta Language - Revision 1143:6e5630ea85d8: Change: rename base_sprites to base_graphics (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/6e5630ea85d8 17:22:50 <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: airportsplus (Diffsize: 1), belarusiantowns, frenchtowns, indonesiantowns (1 errors) (Diffsize: 1), manindu (Diffsize: 1), narvs, newgrf_makefile, ogfx-industries, ogfx-landscape, ogfx-trains (Diffsize: 1), spanishtowns, swedishrails (Diffsize: 6), swisstowns 17:25:39 <planetmaker> hm, not starting at 0... yes, possibly cmd line argument is the most sensible 17:27:45 <Ammler> planetmaker: the ogfx-rv is a issue with new check.md5, will you fix that or do I need to change it on the default build settings? 17:28:59 <planetmaker> hu? 17:30:30 <planetmaker> can you tell me what is actually wrong? 17:30:33 <planetmaker> or different? 17:30:33 <Ammler> you create check.md5 also for non source bundles? 17:30:56 <planetmaker> I don't think so 17:31:22 <planetmaker> non-source bundles don't need that 17:31:40 <planetmaker> and actually: I must not 17:32:01 <planetmaker> otherwise I create a bundle_zip from a source bundle - and voilà - I've overwritten the check.md5 17:32:38 <Ammler> but but, why does ogfx-rv have one? :-) 17:33:18 <planetmaker> you built it from source? or it was explicitly asked to be built? 17:33:32 <Ammler> don't think so 17:33:51 <planetmaker> a source bundle will differ from the checkout always by the ...check.md5 17:34:00 <planetmaker> an some Makefile addition 17:34:05 <Ammler> hmm 17:34:36 <planetmaker> but I don't understand why that now should lead to an error. It's like that literally for months 17:34:41 <Ammler> I guess, I am wrong 17:34:43 <planetmaker> if not even a year or so 17:34:49 <Ammler> it had check.md5 but not anymore 17:35:14 <Brot6> 2cc train set - Support #2211: Feedback from the community / playerbase (Voyager1) @ http://dev.openttdcoop.org/issues/2211#change-5656 17:36:08 <Brot6> 2cc train set - Feature #2235 (New): Toronto H-series (Voyager1) @ http://dev.openttdcoop.org/issues/2235 17:42:09 *** ODM has joined #openttdcoop.devzone 17:59:07 *** DanMacK has quit IRC 18:46:02 *** andythenorth has joined #openttdcoop.devzone 19:03:21 <Brot6> 32bpp-ez-patches: update from r21931 to r21937 done (2 errors) - http://bundles.openttdcoop.org/32bpp-ez-patches/testing/r21937 19:06:14 <Brot6> clientpatches: update from r21488 to r21488 done - http://bundles.openttdcoop.org/clientpatches/testing/r21488 19:07:26 <Brot6> serverpatches: compile of r21937 still failed (#2080) - http://bundles.openttdcoop.org/serverpatches/testing/ERROR/r21937 19:22:47 <DJNekkid> planetmaker: i think this might be in your spirit: http://bugs.openttd.org/task/4458 19:24:08 <planetmaker> what about starting the vehicle? 19:24:17 <planetmaker> wouldn't it be inconsistent? 19:24:23 <DJNekkid> the "green button" in the depot window? 19:24:44 <DJNekkid> atleast that is what i do when when i make multiple clones 19:24:57 <planetmaker> yes, me too. 19:25:09 <planetmaker> I'm just not sure... it would break GUI consistency somewhat 19:25:57 <DJNekkid> could ofcourse be made an option in the 'interface' section 19:26:21 <DJNekkid> i just got the idea last night (literarely, around 4am) when playing a paxdest game with chillcore 19:26:34 <DJNekkid> and i were constatnly building tram networks in some large citites 19:26:49 <DJNekkid> where i made 2x10 trams (10 clockwise, 10 anticlockwise) 19:27:03 <DJNekkid> and i thought: Why do theese keep popping up exactly... 19:27:46 <DJNekkid> as there is absolutely no need for it as far as i could see... 19:28:52 <planetmaker> it could be coupled to the building tool setting. A new one... I don't fancy many options ;-) 19:29:17 <planetmaker> but in principle you're right. For cloning it's not needed. 19:29:23 <DJNekkid> as i had to 'pin' the two depot windows, and then press delete to remove the first ten, and then shift-del to remove all windows all together 19:29:33 <planetmaker> :-) 19:29:39 <planetmaker> what I do, too, yes 19:29:47 <DJNekkid> to many clicks :P 19:29:57 <DJNekkid> why not just CTRL-click-click.....click 19:30:05 <DJNekkid> and grenn button, then the X :) 19:30:06 <DJNekkid> hehe 19:30:11 <DJNekkid> *green 19:31:52 <planetmaker> :-) 19:57:05 <DJNekkid> so, committing it? :P 20:30:33 <Hirundo> I tend to agree with pm: "I'm just not sure... it would break GUI consistency somewhat" 20:30:53 <DJNekkid> as an interface option then... 20:31:01 <DJNekkid> as its MUCH less harrasment :) 20:31:04 <planetmaker> DJNekkid: not in that form... it has issues most possibly 20:31:29 <DJNekkid> i'll add it to a local build and see if i can spot anything 20:32:15 <DJNekkid> but on http://wiki.openttd.org/Compiling_on_MinGW it saies: 20:32:21 <DJNekkid> tar xvfz zlib-1.2.5.tar.gz 20:33:32 <DJNekkid> but that does not work: c:/dev/msys/1.0/bin/tar.exe: you must specify on of the '-Acdtrux' options 20:33:38 <DJNekkid> and i did try -xvfz as well 20:33:52 <Rubidium> old msys? 20:34:13 <Rubidium> I'd think that the version mentioned in the manual would work 20:34:58 <DJNekkid> i did click this link:http://sourceforge.net/projects/mingw/files/Automated%20MinGW%20Installer/mingw-get-inst/mingw-get-inst-20101030/mingw-get-inst-20101030.exe/download 20:35:00 <Webster> Title: Download MinGW - Minimalist GNU for Windows from SourceForge.net (at sourceforge.net) 20:35:10 <DJNekkid> and it downloaded and things 20:35:35 <Rubidium> odd; try to remove the v and z, so tar xf zlib-1.2.5.tar.gz 20:35:54 <DJNekkid> same error 20:36:02 <DJNekkid> also with -xf 20:36:32 <Rubidium> that makes *no* sense 20:37:09 <Rubidium> did you have mingw and the likes installed before on your system? 20:38:03 <DJNekkid> i dont _think_ so, but i guess i could uninstall and try again :) 20:39:35 <Hirundo> There are already too many settings, IMO 20:40:09 <Hirundo> To misquote someone: "Every problem can be solved by adding a setting, except having too many settings" 20:40:22 <DJNekkid> hehe 20:41:12 <Rubidium> Hirundo: nah... that can't be true 20:41:12 <andythenorth> Hirundo: have another setting: 20:41:21 <andythenorth> settings: some | lots 20:41:34 <Rubidium> today someone had a problem that could be fixed by removing a setting 20:41:39 <planetmaker> that's not the first time that thought was thought, andythenorth ;-) 20:41:54 <Rubidium> and FS#4456 can be solved by removing a setting as well 20:41:54 * andythenorth is a fan of sensible defaults :P 20:41:58 <planetmaker> Rubidium: and I still favour that solution :-) 20:42:44 <DJNekkid> that is true Rubidium 20:43:11 <DJNekkid> and that is a setting i would imagine everyone use 20:44:47 <Hirundo> I'd consider making 'clone with shared orders' work without ctrl-magic a higher priority 20:45:57 <DJNekkid> 4458? 20:47:13 <andythenorth> consists! 20:47:18 <andythenorth> orders! 20:47:33 <andythenorth> planetmaker: I broke compatibility of FIRS nightly :P 20:47:37 <andythenorth> should I update min version? 20:47:50 <Brot6> FIRS Industry Replacement Set - Revision 1661:64fca886abd5: Change: modify forge acceptance and c... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/64fca886abd5 20:47:50 <Brot6> FIRS Industry Replacement Set - Revision 1662:6281ecd90110: Change: (translations) Forge industry... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/6281ecd90110 20:47:52 <andythenorth> in fact, can min version just auto-increment to 'current rev' ? 20:48:09 <planetmaker> andythenorth: of course you should update min_version 20:48:22 <planetmaker> but it cannot auto-increment 20:50:07 <andythenorth> why not? :o 20:50:47 <Hirundo> That'd defeat it's purpose 20:51:11 <andythenorth> ho 20:51:13 <andythenorth> :( 20:51:41 * andythenorth considers some kind of commit hook to bump min version 20:52:50 <andythenorth> maybe 25% of commits are savegame unsafe 20:53:07 <andythenorth> that's quite a lot of bumping I have to remember to do 20:53:23 <andythenorth> how many downloads to nightlies actually get? 20:53:33 <andythenorth> what happened to 'use nightly at your own risk' ? 20:53:41 <Hirundo> I guess, min_version is mostly useful for 'stable branches' 20:54:07 <Hirundo> nightly users generally know what they're doing anyways 20:54:36 <planetmaker> andythenorth: well, own risk, sure. Even when Hirundo is right, I think it's sensible to exercise that in order to remember and not forget it 20:55:19 <planetmaker> also... what you *could* do, andythenorth: keep the 'old' layouts till just before the stable release as additional layouts 20:55:36 <planetmaker> can you forbid a layout to be built? 20:56:55 <andythenorth> :( 20:57:21 <andythenorth> I refer you to http://bugs.openttd.org/task/4131?project=1&pagenum=3 20:57:26 <andythenorth> which I should try and fix 20:57:32 <andythenorth> but it's so far beyond me 20:57:38 <andythenorth> I can write some game code happily 20:57:57 <andythenorth> but nested functions with insane numbers of parameters are beyond me so far 20:58:06 <planetmaker> that's why I was asking. I was not sure whether it was / has been worked on. 20:58:10 <andythenorth> I tried to fix it and just ended with a broken mess 20:58:24 <andythenorth> it's needed for a decent FIRS 20:58:36 <DJNekkid> eek 21:00:03 <DJNekkid> when i try to wget: "the program cant start because msys-crypto-1.0.0.dll is missing on your computer" 21:00:14 <planetmaker> that's in parts of the code I've not explored yet either 21:00:47 <andythenorth> planetmaker: now I started working with vehicle and drawing code... 21:00:57 <andythenorth> ....I realised just how insane a lot of the industry code is 21:01:12 <planetmaker> quite, yes 21:01:13 <andythenorth> it's just incredibly hard to follow unless you know the spec inside out 21:01:19 <andythenorth> and has lots of special cases 21:01:31 <andythenorth> and when I read some of the special cases, they were extra special 21:01:37 <andythenorth> i.e. broken 21:01:41 <andythenorth> and not in spec :P 21:01:59 <andythenorth> am I encouraging you to pick up this problem? :D 21:02:21 <planetmaker> totally 21:02:26 <planetmaker> sounds like a 5 minute job :-P 21:02:33 <andythenorth> frosch123 thought it wasn't too hard actually 21:02:39 <planetmaker> look. see. run. 21:02:42 <andythenorth> you just have to have a clear idea of what to do 21:04:17 <andythenorth> I don't :( 21:05:20 <frosch123> according to forums about anything "can't be that hard" 21:05:40 <andythenorth> well in this case you actually told me what to do 21:05:41 <andythenorth> :) 21:05:44 <andythenorth> I just couldn't do it 21:05:50 <andythenorth> I even have a transcript somewhere 21:08:02 <planetmaker> is there a limit on the number of layouts? 21:08:14 * andythenorth looks in spec 21:08:31 <andythenorth> stupid flyspray has help keys :P 21:09:23 <andythenorth> planetmaker: num layouts is a byte...so I guess there's a limit :) 21:09:45 <planetmaker> :-) 21:12:52 * andythenorth can't find the transcript :( 21:12:56 <andythenorth> sometime in october last year 21:57:31 <Brot6> FIRS Industry Replacement Set - Revision 1663:2ed28a9eae31: Add: pnfo files for ironworks (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/2ed28a9eae31 21:57:31 <Brot6> FIRS Industry Replacement Set - Revision 1664:df75ee1b1f8b: Change: (translations) add English st... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/df75ee1b1f8b 21:57:31 <Brot6> FIRS Industry Replacement Set - Revision 1665:2da8d205bc43: Change: (translations) industry windo... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/2da8d205bc43 21:57:35 <Brot6> FIRS Industry Replacement Set - Revision 1666:d1679ed67175: Change: Iron Works uses correct indus... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/d1679ed67175 22:03:06 *** frosch123 has quit IRC 22:03:35 <andythenorth> 333 commits to FIRS 2k :P 22:04:12 <Brot6> FIRS Industry Replacement Set - Revision 1667:3998b46e8485: Change: Iron Works uses correct path ... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/3998b46e8485 22:11:50 <Brot6> FIRS Industry Replacement Set - Revision 1668:e0fc7d13053a: Change: set Iron Works closure date (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/e0fc7d13053a 22:18:49 <Brot6> FIRS Industry Replacement Set - Revision 1669:f9e692ac5634: Change: rename cb28 colocation templa... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/f9e692ac5634 22:18:49 <Brot6> FIRS Industry Replacement Set - Revision 1670:d12b68fcb209: Change: Iron Ore Mine and Forest no l... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/d12b68fcb209 22:19:51 <Brot6> FIRS Industry Replacement Set - Revision 1671:6a3438bc2e13: Change: Iron Works tries to locate ne... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/6a3438bc2e13 22:32:42 <Brot6> FIRS Industry Replacement Set - Revision 1672:c7dc25495b6f: Change: Iron Works clustering value t... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/c7dc25495b6f 22:34:54 *** ODM has quit IRC 22:35:48 <Brot6> FIRS Industry Replacement Set - Bug #2236 (New): Consider colocating more primary / secondary ind... (andythenorth) @ http://dev.openttdcoop.org/issues/2236 22:35:54 <andythenorth> bed time 22:35:56 <andythenorth> good night 22:35:58 *** andythenorth has left #openttdcoop.devzone 22:41:13 <Brot6> 2cc train set - Feature #2237 (New): Munchen MVG A2 (Voyager1) @ http://dev.openttdcoop.org/issues/2237 22:42:25 <Brot6> FIRS Industry Replacement Set - Feature #2011 (Resolved): Change forge -> Ironworks + Blacksmith (andythenorth) @ http://dev.openttdcoop.org/issues/2011#change-5657 23:00:25 <planetmaker> thanks for the base_graphics support, Yexo - I'm having fun with it :-) 23:01:31 <V453000> how to satisfy a madman :P 23:02:42 <planetmaker> haha :-) 23:03:13 <Yexo> are recolor sprites now the only missing feature for full baseset support? 23:03:57 <planetmaker> I think so. I haven't actually tested whether grfcodec would get confused by several consecutive grf file headers 23:04:01 <planetmaker> they get always written 23:04:33 <planetmaker> but that's ok - as nml is not made for having its output concatenated afterwards 23:10:16 <Yexo> no, that doesn't matter 23:10:19 <Yexo> it's just comments 23:12:29 <Yexo> --disable-nfo-header <- suggestions for a better name? (as commandline option) 23:14:03 <planetmaker> then there's no need to disable it actually 23:14:12 <planetmaker> if so, it's a good name 23:16:24 <planetmaker> this does convince NML to accept a sprite number offset. But it doesn't convince it yet to use it for NFO output 23:16:29 <planetmaker> http://paste.openttdcoop.org/show/95/ 23:20:23 <planetmaker> hm... snow outside... 23:21:25 <Yexo> planetmaker: revert the last block, and change the for loop there to: for num, action in enumerate(actions, start_sprite_num): 23:21:39 <Yexo> + start_sprite_num = opts.start_sprite_num <- that line can be left out 23:21:52 <Yexo> +start_sprite_num = 0 <- as can that line 23:22:42 <Yexo> that syntax needs python 2.6, was that already a requirement or did python 2.5 still work? 23:24:15 <planetmaker> I don't know... I guess I can test at work tomorrow 23:24:24 <planetmaker> IIRC it did 23:28:30 <Yexo> http://devs.openttd.org/~yexo/start_sprite.diff seems to work fine 23:31:40 <DJNekkid> that little line of Chilldore were doing its job very nice 23:31:43 <DJNekkid> *chllcore 23:33:04 <DJNekkid> chillcore god damn it 23:33:06 <planetmaker> indeed it does, Yexo 23:33:29 <planetmaker> but there's one quirk: the default offset should be 0 and not 3092 ;-) 23:33:37 <Yexo> indeed, I copied that from you :p 23:33:43 <planetmaker> yep :-P 23:35:14 <Brot6> NewGRF Meta Language - Revision 1144:d7b4a96cc3b9: Add: commandline option to specify sprite numb... (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/d7b4a96cc3b9 23:36:20 <planetmaker> DJNekkid: there are concerns of its working in an MP environment. And about GUI consistency. Would people then not think using ctrl is just about not showing the vehicle? 23:36:55 <planetmaker> or should the clone and copy behaviour possibly be re-considered a bit more thoroughly wrt how it works? 23:36:58 *** Lakie has quit IRC 23:37:12 <DJNekkid> well, that is one way to see it :) 23:37:50 <DJNekkid> atleast the idea have come, and there have come a solution... 23:37:57 <DJNekkid> atleast one possible solution 23:38:22 <DJNekkid> btw, chillcore is currently on my server, and he use that 'mod', and i do not and we heavent had a desync yet :D 23:38:29 <planetmaker> it's not a solution should it desync in MP ;-) 23:38:58 <planetmaker> he :-) 23:42:12 <DJNekkid> come join us :D 23:42:34 <DJNekkid> if not for anything else then looking at our network :D 23:44:26 <Yexo> DJNekkid: the problem is not that it'll desync 23:44:46 <Yexo> if you release (or press) ctrl just after clicking on clone vehicle but before the new vehicle appears, the wrong thing will happen 23:45:46 <DJNekkid> oki :D 23:45:49 <DJNekkid> :( :( 23:46:50 <Yexo> that's just an implementation detail though, it can be fixed quite easily 23:47:11 <Yexo> main reason it isn't in yet is what planetmaker already said: it feels inconsistent with the rest of the gui 23:47:11 <DJNekkid> what is your idea about the idea in general btw? 23:47:27 <Yexo> it's a good idea, but it needs a bit more though :) 23:47:32 <Yexo> +t 23:47:45 <DJNekkid> :D 23:47:55 <planetmaker> that was the general concensus ;-) 23:48:13 <planetmaker> s/c/s/ 23:53:14 <DJNekkid> well, i hope you brainy guys find a solution :) 23:57:57 <Ammler> DJNekkid: what is the server running? 23:58:15 <DJNekkid> chillcore patchpack 21900 23:58:37 <Ammler> and you join the server without? 23:59:42 <DJNekkid> yes 23:59:43 <DJNekkid> and he with