Times are UTC Toggle Colours
00:06:38 <Brot6> cets: update from r570 to r571 done (386 warnings) - http://bundles.openttdcoop.org/cets/push/r571 00:13:35 *** andythenorth has quit IRC 00:42:26 <Brot6> TransRapid Track Set - Bug #3616 (New): attempt to use invalid ID (planetmaker) @ http://dev.openttdcoop.org/issues/3616 00:55:48 <Brot6> OpenGFX+ Trains - Revision 296:76348d9edd9d: Feature: Use a verbose railtype translation table, t... (planetmaker) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/76348d9edd9d 01:31:15 <Brot6> FIRS Industry Replacement Set - Bug #3503: Terraform underneath quarry and claypit is possible (YukonRob) @ http://dev.openttdcoop.org/issues/3503#change-9352 04:57:10 <Brot6> Central European Train Set - Revision 572:7c412e531142: Change: fix/raise many MU power and TE va... (oberhuemer) @ http://dev.openttdcoop.org/projects/cets/repository/revisions/7c412e531142 05:16:17 <Brot6> cets: update from r571 to r572 done (377 warnings) - http://bundles.openttdcoop.org/cets/push/r572 05:52:47 <Brot6> Central European Train Set - Revision 573:2b96dfb29e71: Change: Base running cost for electric en... (oberhuemer) @ http://dev.openttdcoop.org/projects/cets/repository/revisions/2b96dfb29e71 06:03:24 <Brot6> Central European Train Set - Revision 574:d9e2bcae8b59: Fix: Wagons became too expensive (oberhuemer) @ http://dev.openttdcoop.org/projects/cets/repository/revisions/d9e2bcae8b59 06:04:36 <Brot6> cets: update from r572 to r573 done (377 warnings) - http://bundles.openttdcoop.org/cets/push/r573 06:08:58 <Brot6> cets: update from r573 to r574 done (377 warnings) - http://bundles.openttdcoop.org/cets/push/r574 07:01:12 *** andythenorth has joined #openttdcoop.devzone 07:01:43 *** LordAro has joined #openttdcoop.devzone 07:42:31 *** andythenorth has quit IRC 08:06:58 *** andythenorth has joined #openttdcoop.devzone 08:20:56 *** LordAro has quit IRC 09:05:22 <Brot6> Central European Train Set - Revision 575:8e8bc97f635e: must have been asleep when making that ch... (Eddi) @ http://dev.openttdcoop.org/projects/cets/repository/revisions/8e8bc97f635e 09:11:27 *** ODM has joined #openttdcoop.devzone 09:12:07 <Brot6> cets: update from r574 to r575 done (377 warnings) - http://bundles.openttdcoop.org/cets/push/r575 09:50:09 *** JVassie has joined #openttdcoop.devzone 10:45:49 *** LordAro has joined #openttdcoop.devzone 10:56:01 <V453000> hello, I am trying to make an articulated wagon but somethign hates me ... I have this http://paste.openttdcoop.org/show/980/ and the compiling says that the "CB_RESULT..." is unrecognized identifier ... I copied it exactly from http://www.tt-wiki.net/wiki/NMLTutorial/Tram_articulation 10:56:15 <V453000> can someone please tell me what am I doing wrong? :) 10:57:14 <V453000> there also is a second issue, the wagon also has a switch based on cargo_type_in_veh 10:57:38 <V453000> and I have no idea how to mix that :) 10:58:58 <V453000> perhaps making a switch block inside a switch block? 11:01:15 <Yexo> which version of nml are you using? 11:02:05 <V453000> sorry but ... where do I read that? :D 11:02:11 <Yexo> nmlc --version 11:02:55 <V453000> r1722 11:03:56 <Yexo> update nmlc :) 11:04:10 <V453000> ok :) 11:04:16 <Yexo> CB_RESULT_NO_MORE_ARTICULATED_PARTS was added in r1756 11:05:12 <Yexo> in a switch you have multiple ranges (like your '1..2') with a return and a default with also a return 11:05:24 <Yexo> instead of "return value;" you can also put "name_of_other_switch_block" there 11:05:40 <Yexo> it'll go to that switch-block, you can return a value from there (or refer to yet another switch-block 11:06:16 <V453000> ah right! :) thanks I will try 11:09:06 <V453000> hm I guess more things changed in nml :D 11:09:22 <V453000> none of the trains is in the newgrf it seems :D 11:09:29 <V453000> only the one wagon 11:09:37 <V453000> which is weird, all are defined the same way 11:10:20 <Yexo> oh, a flatbad that transports CC_REFRIGERATED? 11:10:26 *** frosch123 has joined #openttdcoop.devzone 11:10:29 <V453000> hm ok all wagons work 11:10:45 <V453000> yes it does :) 11:10:53 <V453000> has fruit, food and stuff 11:10:59 <Yexo> ah, ok 11:11:51 <Yexo> perhaps disallow CC_LIQUID? 11:12:19 <V453000> http://paste.openttdcoop.org/show/981/ this is how I define an engine ... all engines seem to be disabled now so I guess I have some issue there ... it worked with the previous versions 11:12:23 <Yexo> that way you don't have to explicitely exclude BEER and MILK, and it'll work properly if somebody decides to add another drink 11:12:24 <V453000> hm yeah perhaps :) 11:12:52 <Yexo> you don't have to set refittable_cargo_classes at all for engines 11:13:06 <Yexo> just set cargo_capacity to 0 11:13:39 <V453000> that one should actually be passenger train 11:14:02 <Yexo> but it has no capacity? 11:14:03 <V453000> the cargo capacity should be, say 20 then 11:14:07 <Yexo> ah, ok :) 11:14:24 <Yexo> no idea why that train doesn't show up, the code looks ok 11:14:27 <Yexo> are you past 2080? 11:14:39 <V453000> yeah 11:14:54 <V453000> no train shows up 11:15:58 <V453000> I have the original engines kept there (for now) so only those load, and wagons of my set. But not a single engine for some reason 11:16:15 <andythenorth> you don't want to exclude CC_LIQUID ;) 11:16:20 <andythenorth> violates the spec 11:16:21 <andythenorth> http://newgrf-specs.tt-wiki.net/wiki/Action0/Cargos#CargoClasses_.2816.29 11:16:28 <andythenorth> never exclude 'base' classes 11:16:44 <V453000> if I have them allowed in a tanker? 11:16:55 <Yexo> andythenorth: sorry to say, but that's stupid 11:17:09 <andythenorth> Yexo: not my spec 11:17:10 <Yexo> you shouldn't exlude it in all your vehicles, but exluding in some should be fine 11:17:30 <andythenorth> it was like...10 days of discussion and multiple drafts 11:17:33 <V453000> yeah, I have it disallowed in flatbed now, but allowed in tanker 11:18:00 <andythenorth> you just disallowed milk in crates or churns ;) 11:18:09 <Yexo> I can see the reasoning if you want to have multiple representations 11:18:24 <Yexo> but why not disallow milk in crates/churns on a flatbad wagon? 11:18:30 <V453000> I do not have milk drawn in crates or churns anyway 11:18:42 <andythenorth> you're doing it wrong ;) 11:18:51 <V453000> mhm :) 11:18:57 <andythenorth> cargo classes are to ensure vehicles are provided for unknown cargos 11:19:04 <Yexo> so he's doing it right 11:19:19 <andythenorth> no 11:19:27 <Yexo> the only thing you have to ensure is that for every combination of cargo classes there is at least one vehicle able to transport it 11:19:32 <andythenorth> trying to exclude unknown cargos with classes is doing it wrong ;) 11:19:43 <Yexo> I disagree 11:20:05 <V453000> I see what andythenorth means, but as I do not want to allow any kind of other milk than tanker, I do it that way 11:20:10 <andythenorth> yexo change the spec 11:20:17 <andythenorth> provide a better one ;) 11:20:26 <Yexo> I'm not going there again 11:20:35 <Yexo> this part of the spec is 'only' a recommendation anyway 11:20:37 <andythenorth> so the spec is invalid? 11:20:46 <V453000> it works doesnt it? 11:20:48 <Yexo> not invalid, just my interpretation is different from yours 11:21:01 <andythenorth> kind of useless though 11:21:06 <andythenorth> we might as well just rm it 11:21:21 <andythenorth> if classes are just interpretation, the idea of compatibility is binned 11:21:38 <Yexo> andythenorth: it has always been that way 11:21:56 <andythenorth> so why bother at all? 11:21:57 <Yexo> there is nobody to ensure 'correct' (whatever that is) usage of cargo classes 11:22:25 <Yexo> all known interpretations are more or less compatible 11:23:35 <andythenorth> meh :) 11:23:42 <andythenorth> I'd seriously rm the spec in that case 11:23:50 <V453000> oh 2cc set is not in nml :o 11:24:12 <andythenorth> it's bizarrely pointless to have a spec that is shot down as 'wrong' as soon it's referred to 11:24:19 <V453000> wanted to look for a difference in my engine definition :z 11:24:40 <Yexo> andythenorth: not the whole spec, I just personally disagree with the "never exlucde the base cargo classes" 11:24:59 <Yexo> You provided a good argument for it, but I'm still not convinced 11:25:14 <andythenorth> it's empirically proven to be a problem 11:25:21 <Yexo> but in the end that's of minor importance 11:26:19 <andythenorth> the aim of trying to tightly control future refitting is imho invalid 11:26:32 <Yexo> of course 11:26:49 <V453000> does NML have a changelog somewhere? so I could try to find the difference 11:27:33 <Yexo> http://hg.openttdcoop.org/nml 11:27:44 <Yexo> and a changelog.txt in docs/, but that's only used for stable versions 11:28:11 <Yexo> you could also use nfo output (from both nml versions) and run a diff over that 11:29:51 <V453000> hm guess I am not going to find it too easily 11:31:29 <V453000> how do I use the nfo output? 11:31:44 <Yexo> -o output.nfo instead of -o output.grf 11:31:49 <Yexo> or --nfo output.nfo 11:32:24 <V453000> right 11:34:05 <V453000> oh :D nfo isnt some readable text? 11:34:35 <Yexo> you never tried creating a grf in nfo? 11:34:40 <V453000> no 11:34:48 <Yexo> that's the whole reason I started nml 11:39:53 <V453000> hm :\ I compiled an output.nfo using both versions, how do I compare it? 11:40:06 <Yexo> diff -u output1.nfo output2.nfo > changes.diff 11:41:45 <V453000> guess that doesnt work in windows cmd eh :D 11:41:56 <Yexo> no :p 11:42:02 <V453000> well, shit :D 11:42:03 <Yexo> just pastebin both nfo files somewhere 11:43:28 <V453000> http://dl.dropbox.com/u/20419525/nuts_newer.nfo newer version, http://dl.dropbox.com/u/20419525/nuts_older.nfo older version 11:44:37 <Yexo> that's not nfo output 11:44:56 <Yexo> did you use "--grf nuts_older.nfo"? 11:45:45 <V453000> in compile.bat? 11:45:49 <Yexo> <V453000> oh :D nfo isnt some readable text? <- nfo is readable text, just it's encoded using hex bytes, so not really "readable" 11:45:55 <Yexo> yes, or however you compile 11:45:55 <andythenorth> Yexo: not sure why I'm so grouchy - sorry. Maybe lack of sleep. Maybe bad character :P 11:46:03 <V453000> nmlc -c --default-lang=english.lng --grf=nuts.nfo nuts.nml 11:46:12 <V453000> guess I did 11:46:18 <Yexo> V453000: replace the --grf with --nfo (or -o) 11:46:27 <V453000> xD 11:46:31 <V453000> ök 11:46:41 <Yexo> with -o nml autodetecs the output type from the extension 11:46:55 <Yexo> with --grf you override that check and force it to write a grf (even though you provide a filename with an nfo extension) 11:47:05 <planetmaker> Yexo: V453000, disallowing the 'base' cargo classes like piece, liquid or bulk is probably not a good idea 11:47:06 <Yexo> andythenorth: no need to apologize 11:47:14 <planetmaker> as a liquid can be transported in barrels or bottles 11:47:55 <V453000> and I was wondering why the grf looks the same as the nfo output! 11:47:57 <V453000> :D 11:49:09 <Yexo> planetmaker: but using that argument every wagon will be able to transport over half the cargo types in a game 11:49:16 <Yexo> imo it's good to have some variety 11:49:41 <planetmaker> yes. But you can (and should) disallow the cargos via the explicit cargo disallow property 11:49:51 <planetmaker> the reason behind to not exclude is along this: 11:50:12 <planetmaker> consider "building material" as cargo. It could be, say, cement or bricks. 11:50:25 <planetmaker> Thus it gets bulk + powerderized. And piece 11:50:49 <planetmaker> thus you can make a vehicle transport bulk and it will fit. And you can make it transport piece and it will fit 11:51:13 <planetmaker> imho allowing this double categorization was the whole point... 11:52:19 <andythenorth> Yexo: "every wagon will be able to transport over half the cargo types in a game" <- rely solely on classes for refits to known cargos is the problem there? 11:52:22 <V453000> Yexo: 2nd try :) http://dl.dropbox.com/u/20419525/nuts_2ndtry_newer.nfo http://dl.dropbox.com/u/20419525/nuts_2ndtry_older.nfo 11:52:35 * andythenorth ponders 11:52:41 <andythenorth> if there is no single spec... 11:52:45 <andythenorth> and no enforcer of spec 11:52:47 <andythenorth> options 11:52:56 <andythenorth> (1) openttd takes on enforcing the spec 11:53:14 <andythenorth> - e.g. physically restrict what can and can't be combined 11:53:36 <andythenorth> (2) FIRS declares that it implement YACS version of spec (Yet Another Cargo Schema) 11:53:45 <andythenorth> other people choose to be YACS compliant or not 11:53:49 <Yexo> planetmaker: ok, it makes sense 11:54:06 <andythenorth> - I then refuse to deal with bug reports or feature requests for non-YACS compliant sets 11:54:38 <andythenorth> (3) we have groundhog hour / day / week every few months wrt classes - what larfs :) 11:54:48 <andythenorth> which option do *you* prefer? 11:55:15 <Yexo> andythenorth: (4) FIRS declares to implement FIRS-version of the spec (you chose cargo labels and classes). Vehicle set authors will just have to follow your lead (and George's if they want to support ECS) 11:56:03 <Yexo> as long as your definition of cargoes is more or less stable vehicle set authors will use that anyway 11:56:09 <andythenorth> 4 ~= 2 11:56:24 <Yexo> yes, basically what we have now 11:56:25 <andythenorth> I don't agree 100% with YACS, it's Eddi's proposal, but I'm prepared to support it 11:56:36 <Yexo> ehm, no 11:56:36 <andythenorth> my spec would be...leaner with fewer classes 11:56:40 <Yexo> I meant just go on like now 11:56:54 <Yexo> chose cargo classes according to how you think they should work 11:57:12 <Yexo> vehicle set authors will be forced to follow your lead or their vehicle set won't work 11:57:36 <V453000> there are some differences between the nfo things but they seem to be pretty much everywhere :o 11:58:22 <V453000> all the keywords in the beginning are +3 11:58:49 <V453000> like 3490 in newer, 3487 in older ... which I believe is the graphics {} block 11:58:52 <andythenorth> is that fair to vehicle set authors (specifically - how do they know what FIRS spec is?) 11:59:15 <Yexo> V453000: the number directly before the * is unimportant 11:59:23 <V453000> oh :o 11:59:44 <Yexo> andythenorth: how is that different from the current situation? 11:59:54 <Yexo> and how do they know; you document that on the wiki page 12:00:05 <V453000> therse are the only differences I see though :z 12:00:05 <Yexo> http://newgrf-specs.tt-wiki.net/wiki/CargoTypes <- it's even already there 12:00:28 <Yexo> V453000: there is one difference, but it has something to do with the flatbed wagon, nothing with any engine 12:00:47 <V453000> hm 12:00:57 <andythenorth> hmm 12:00:58 <V453000> could you run the diff please? :) 12:01:01 <andythenorth> actually it's simple 12:01:02 <andythenorth> yes 12:01:23 <andythenorth> if you want to support FIRS, use explicit labels and the new include / exclude properties 12:01:31 <Yexo> http://devs.openttd.org/~yexo/changes.diff <- V453000 12:01:35 <andythenorth> I'm not prepared to guarantee any support for classes 12:01:50 <planetmaker> andythenorth: yes. You might want to add a footnote to the FIRS labels that authors should NOT rely on the class remaining constant 12:01:55 <andythenorth> in fact, I think we said that last time we discussed this: classes are supposed to be decoupled from cargos, and may vary 12:02:10 <andythenorth> you can't lock the abstraction mechanism in stone, or it fails to abstract :P 12:02:34 <V453000> :< how do I read that? 12:02:55 <V453000> + means the line is equal, - not? 12:03:09 <planetmaker> add that line, remove the other 12:03:12 <andythenorth> by allowing classes may vary, we avoid the fricking insanity of declaring new labels when a class changed :P 12:03:15 <planetmaker> use the patch command to apply 12:03:38 <planetmaker> that was IMHO the point as well, not, andythenorth? 12:03:53 <planetmaker> s/not/right/ 12:04:15 * andythenorth is not entirely good at remembering things 12:04:38 * andythenorth should do a wiki edit 12:05:05 <planetmaker> but granted. If one wants to explicitly support or not support all known cargo labels... it's a very tedious endeavour 12:05:05 <Yexo> V453000: lines between the lines with @@ are one block of code. first character is important: space=line is equal in both files, -=line is in old file, +=line is in new file 12:05:34 <andythenorth> planetmaker: not so much :) 12:05:54 <V453000> Yexo: right, but how do I use this to find my problem? 12:06:13 <Yexo> you: probably not :p 12:06:15 <andythenorth> I'm not saying don't use classes, just don't rely on them 12:06:15 <planetmaker> andythenorth: it is... you have to explicitly think about each cargo and mention it in one of the two properties 12:06:21 <andythenorth> true 12:06:24 <V453000> hm :Z 12:06:27 <Yexo> for me it was useful to see that there are no important differences in the output that both nml versions generate 12:06:50 <Yexo> can you test again whether your file compiled with the old nml version really worked in openttd? 12:07:02 <Yexo> did you test in one openttd version or in multiple versions? 12:07:16 <andythenorth> if I was doing a train set right now, I'd define cpp constants that were lists of appropriate labels for different wagon types 12:07:26 <V453000> Yexo: in one 12:07:31 <andythenorth> as types are fairly low in number 12:07:33 <V453000> r23820 12:07:38 <andythenorth> e.g. REFITS_HOPPER 12:07:42 <andythenorth> REFITS_OPEN_WAGON etc 12:07:50 <V453000> and the old worked for sure 12:08:31 <Yexo> V453000: please try again with r23836 or later 12:08:35 <andythenorth> then the classes are fallback - as intended 12:08:43 <V453000> righto 12:10:14 <andythenorth> hmm 12:10:31 <andythenorth> where should notes about FIRS be added? classes section, labels section or both? 12:10:38 <planetmaker> andythenorth: that's what I have. It's still not handy to create 12:11:07 <planetmaker> but then the old refit properties were also lengthy to create and check. This is easier 12:11:35 <andythenorth> it's a good enough solution 12:11:45 <andythenorth> unless we can devise better, we shouldn't unpick it too soon ;) 12:11:59 <andythenorth> it's consumed enough time 12:12:09 <andythenorth> and the fun : time ratio is not optimal 12:12:27 <V453000> Yexo: both work in new trunk of openttd :D 12:12:35 <Yexo> great :) 12:12:48 * andythenorth wants instead to get on with re-coding BANDIT (again) - but has obligations :P 12:13:13 <V453000> next time I automatically update both nml and openttd :D 12:13:35 <V453000> thank you very much Yexo :) 12:13:46 <Yexo> you're welcome :) 12:15:42 <V453000> now back to the articulation! :D 12:16:16 <planetmaker> 13:13 V453000: next time I automatically update both nml and openttd :D <-- always a good idea when testing newgrfs. And tbh especially with nml 12:16:32 <V453000> :) I am sure I will remember that now pm :p 12:16:44 <planetmaker> but also the grf v8 transition might need or another bug fix... it's not like it got extensive tests ;-) 12:16:51 <andythenorth> it's something like: "FIRS does not guarantee that classes won't vary. Feel free to use classes in your set for conveniently refitting to FIRS cargos, but if you - the vehicle author - care about specific cargos being transported in specific vehicles, use label based refits" 12:17:11 <planetmaker> yes 12:17:35 <andythenorth> I think that's fair, and reflects the cascading order of the newgrf spec correctly too 12:18:37 <Yexo> andythenorth: but that's almost a given 12:18:47 <Yexo> george has done that twice already for ECS cargoes 12:19:02 <andythenorth> I think it needs the disclaimer :P 12:19:07 <andythenorth> otherwise there are tiresome dramas 12:19:17 <andythenorth> and I get accused of causing people to leave the community etc 12:19:26 <andythenorth> and I get irritated pms 12:19:37 <andythenorth> (and irritated planetmakers too) 12:19:38 <andythenorth> :P 12:21:02 <andythenorth> on the other hand....forgiveness > permission :) 12:22:11 <Yexo> yes, such a disclaimer is a probably a good diea 12:22:17 <Yexo> however make it more general than just for FIRS 12:22:22 <andythenorth> yes 12:22:35 <andythenorth> it's bad style to add notes about specific newgrfs to the wiki 12:22:46 <andythenorth> also...it is a general note on classes worth knowing 12:23:04 <V453000> so now I have this :) http://paste.openttdcoop.org/show/982/ what I am trying to do is to make a switch block with articulation, which outputs the other cargo_type_in_veh switch ... but in the game it doesnt load the sprite ... what could be wrong? 12:23:56 <Yexo> you're adding it at the wrong place 12:24:02 <V453000> I guess :) 12:24:12 <Yexo> the articulated callback is only for determining how many parts to add 12:24:24 <Yexo> it should never return a spritegroup like you do now 12:24:29 <V453000> oh 12:24:48 <Yexo> in your graphics block, add "default: maglevflatbed_wagon_switch;" 12:24:49 <V453000> so it has to return the item_maglevflatbed 12:24:57 <V453000> ok 12:24:59 <Yexo> yes, exactly 12:25:55 <andythenorth> any good? http://newgrf-specs.tt-wiki.net/wiki/Action0/Cargos#CargoClasses_.2816.29 12:26:33 <Yexo> yes :) 12:27:20 <V453000> great! :) Now the ohly problem was that I wanted 2 additional parts instead of one ... but works like charm now :))) thanks 12:27:37 <andythenorth> hmm 12:27:43 <andythenorth> there is also this page to edit http://newgrf-specs.tt-wiki.net/wiki/Action0Trains#Cargo_classes_.2828.2C_29.29 12:28:02 <andythenorth> that also references prop 1D still 12:28:13 <andythenorth> which we really ought to deprecate 12:28:18 <andythenorth> it's neither intuitive nor safe 12:28:54 * andythenorth needs to do baby things though 12:30:13 <V453000> you can consider me a baby for now 12:30:21 <V453000> I am as happy as a baby at the moment 12:35:56 <andythenorth> I've copied the disclaimer into the train page stuff 12:43:32 <Brot6> Dutch Trains 2.0 - Revision 100:21bfdcec4bf3: Feature: NS1100 graphics for HSM126/NS1100 (graphic... (foobar) @ http://dev.openttdcoop.org/projects/dutchtrains/repository/revisions/21bfdcec4bf3 12:46:20 <V453000> I will try to be annoying a bit more: I want to make my passenger trains be compatible only with passenger wagons - not other wagons. How do I do that? I cant seem to find it on the wiki 12:48:00 <Hirundo> There's a callback for that 12:48:05 <Hirundo> IIRC can_attach_wagon 12:49:16 <V453000> ah right 12:49:18 <V453000> thanks 12:49:54 <Brot6> GRFCodec - Revision 857:c4d92223f9b1: -Add: Action 0 cargo property 1D. (frosch) @ http://dev.openttdcoop.org/projects/grfcodec/repository/revisions/c4d92223f9b1 12:50:08 <andythenorth> hmm 12:50:14 <andythenorth> calling eval() is really not the done thing 12:55:00 <andythenorth> yay 12:56:14 <V453000> hm, where do I actually use the callback though? guess not in the graphics{} 12:57:37 <Hirundo> you add it to the graphics block 12:59:46 <V453000> works! great thanks Hirundo :) 13:03:09 <andythenorth> nml ftw 13:04:25 <V453000> hm, how do I allow multiple wagons to be attachable though? if I copy the callback multiple times, it doesnt work, and if I write it into one callback separating the item names by commas, it doesnt work either :| 13:11:54 <Hirundo> Could you copy paste your current code? 13:12:03 <V453000> sec. 13:12:35 <V453000> http://paste.openttdcoop.org/show/983/ I tried this 13:12:47 <V453000> I want that train to attach those 3 wagons exclusively 13:14:00 <Hirundo> I doubt that that worked even for one vehicle 13:14:25 <V453000> for one wagon it does 13:14:40 <V453000> it just returns undefined string errors when trying to add a different wagon 13:16:00 <V453000> question is how to make it for 3 :o 13:16:09 <Hirundo> "undefined string errors" isn't what I call working 13:16:18 <V453000> for now it is 13:16:23 <Hirundo> also, those errors probably appear for the 'right' wagon also 13:16:29 <V453000> I guess adding the error strings can be done later 13:16:48 <V453000> oh they do indeed :D 13:16:52 <V453000> didnt test that 13:17:38 <Hirundo> So, by reasonable definition, we can agree that it doesn't work right now 13:17:57 <Hirundo> You should start by reading the description of the can_attach_wagon callback more closely 13:18:22 <V453000> cant say I understand that much 13:20:06 <Hirundo> Basically, you have to check the ID of the wagon being attached via a switch block 13:21:12 <Hirundo> then return CB_RESULT_ATTACH_ALLOW to allow attaching 13:21:27 <V453000> aha 13:21:30 <Hirundo> or return CB_RESULT_ATTACH_DISALLOW to disallow attaching 13:21:36 <V453000> right :) 13:21:41 <Hirundo> or return a custom string to disallow with a nice error message 13:22:02 <Hirundo> you will probably want to use two switch blocks for those checks 13:22:06 <Hirundo> first one to check grfid 13:22:21 <Hirundo> second to check the vehicle ID 13:24:19 *** andythenorth has quit IRC 13:36:27 <V453000> http://paste.openttdcoop.org/show/985/ I guess this makes more sense, but how do I call the vehicle ID please? :) 13:37:21 <Hirundo> switch should be placed before the item bloc 13:37:44 <V453000> I have that, I just pasted it here vice versa 13:38:02 <V453000> but the identifier/train_id/wagon_id/vehicle_id I tried but neither is accepted :) 13:38:07 <Hirundo> 'identifier' should be vehicle_type_id 13:38:33 <Hirundo> and strings are done via string(STR_XXX) with STR_XXX defined in your lang file 13:38:45 <Hirundo> So it can be translated into a gazillion different languages 13:39:24 <V453000> oh right :) 13:41:24 <Yexo> V453000: wher eyou have identifier you can use variables. For vehicles a list can be found here: http://newgrf-specs.tt-wiki.net/wiki/NML:Vehicles#Vehicle_variables 13:44:58 <V453000> nmlc: internal error has occured :o 13:45:36 <Hirundo> o_0 13:45:40 <V453000> error :(value error)<substring not found> 13:45:54 * Hirundo is confuzzled 13:45:59 <Hirundo> what code triggers that? 13:46:53 <V453000> I dont know :O I put all things I added into comments and it doesnt fix 13:47:41 <V453000> I see 13:48:04 <V453000> I added the string in english.lng and custom_tags.txt 13:48:06 <V453000> and then it broke 13:48:27 <V453000> but I did it exactly the same way as the other strings ... which work 13:48:49 <Hirundo> Could you paste english.lng and custom_tags.txt somewhere? 13:49:30 <V453000> I think I already found it 13:49:36 <V453000> I used // in these files 13:49:40 <V453000> that cant be done? 13:50:04 <V453000> ... I removed that and now it compiles 13:51:38 <Hirundo> Nothing should ever trigger an internal error 13:52:19 <V453000> if I place a line "//test" in either english.lng or custom_tags.txt, it breaks 13:53:02 <V453000> an ohly the custom_tags cause teh internal error though 13:54:30 <Yexo> read_extra_commands has no check for missing : in the string indeed 13:55:21 <Hirundo> indeed 13:55:50 <V453000> but my allow wagon works now :P thank you 13:58:57 <Yexo> V453000: in english.txt you can start comments with # 13:59:02 <Brot6> NewGRF Meta Language - Revision 1800:71afdc6c3d28: Fix: don't crash when a line in custom_tags.tx... (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/71afdc6c3d28 13:59:04 <Yexo> in custom_tags.txt no comments are allowed 13:59:20 <Yexo> currently, that is. If someone wants to add support for # there too that'd be fine with me 13:59:58 <Brot6> Dutch Trains 2.0 - Revision 101:824891efcbf9: Fix (r100): use CB_RESULT_NO_MORE_ARTICULATED_PARTS... (foobar) @ http://dev.openttdcoop.org/projects/dutchtrains/repository/revisions/824891efcbf9 13:59:58 <Brot6> Dutch Trains 2.0 - Revision 102:13d6b33cf081: Feature: HSM500/NS2100 (graphics by Snail) (issue #... (foobar) @ http://dev.openttdcoop.org/projects/dutchtrains/repository/revisions/13d6b33cf081 13:59:58 <Brot6> Dutch Trains 2.0 - Revision 103:401c62fb5e18: Feature: align trains in depot view (foobar) @ http://dev.openttdcoop.org/projects/dutchtrains/repository/revisions/401c62fb5e18 14:00:00 <Brot6> Dutch Trains 2.0 - Revision 104:7930b8dc2b11: Feature: SS700/NS3700 (graphics by Snail) (issue #3... (foobar) @ http://dev.openttdcoop.org/projects/dutchtrains/repository/revisions/7930b8dc2b11 14:00:29 <Hirundo> Yexo: #-comments work in custom_tags.txt right ? "if len(line) == 0 or line[0] == "#": pass" 14:00:45 <Yexo> oh, right :) 14:01:23 <V453000> oh :) ok 14:02:06 <Hirundo> Yexo: Could you comment on #3583 ? 14:02:07 <Brot6> Hirundo: Yexo: #3583 is http://dev.openttdcoop.org/issues/show/3583 "NewGRF Meta Language - Feature #3583: deprecate / remove refittable_cargo_types - #openttdcoop Development Zone" 14:02:23 <Yexo> sure 14:08:23 <Brot6> NewGRF Meta Language - Feature #3583: deprecate / remove refittable_cargo_types (yexo) @ http://dev.openttdcoop.org/issues/3583#change-9353 14:43:44 <V453000> hm, when I have strings, how do I make them ... red for example? or rather ... where can I find a list of those properties? 14:51:23 <Yexo> http://newgrf-specs.tt-wiki.net/wiki/NML:Language_files 14:51:43 <Yexo> STR_MY_STRING :Some text{RED}Red text{BLACK}Black text 14:51:53 <V453000> my abilities to search are 0 :D thank you so much 14:52:11 <frosch123> V453000: you have to set the search namespace to "NML" 14:52:16 <frosch123> else you will find nothing :p 14:52:54 <V453000> I was just browsing the wiki 14:58:43 <Brot6> Dutch Trains 2.0 - Revision 105:a4f81bf8e334: Feature: NS3800 (graphics by Snail) (issue #3359) (foobar) @ http://dev.openttdcoop.org/projects/dutchtrains/repository/revisions/a4f81bf8e334 14:58:43 <Brot6> Dutch Trains 2.0 - Revision 106:ba206667e24b: Feature: NS3900 (graphics by Snail) (issue #3359) (foobar) @ http://dev.openttdcoop.org/projects/dutchtrains/repository/revisions/ba206667e24b 14:58:43 <Brot6> Dutch Trains 2.0 - Revision 107:291f675012da: Feature: NBDS30/NS3500 (graphics by Snail) (issue #... (foobar) @ http://dev.openttdcoop.org/projects/dutchtrains/repository/revisions/291f675012da 14:58:45 <Brot6> Dutch Trains 2.0 - Revision 108:5bab63285929: Fix (r100, r102, r104): use PARENT scope for date_o... (foobar) @ http://dev.openttdcoop.org/projects/dutchtrains/repository/revisions/5bab63285929 14:58:49 <Brot6> Dutch Trains 2.0 - Revision 109:189132fe1858: Feature: NCS70/NS3600 (graphics by Snail) (closes #... (foobar) @ http://dev.openttdcoop.org/projects/dutchtrains/repository/revisions/189132fe1858 14:58:53 <Brot6> Dutch Trains 2.0 - Feature #3359 (Closed): Templated steamers, per request (foobar) @ http://dev.openttdcoop.org/issues/3359#change-9354 15:15:03 <V453000> how do I use multiple additional_text for the purchase menu? 15:22:47 <frosch123> try {STRING} 15:22:55 <frosch123> but you can only return one top-level text 15:23:47 <V453000> I have that but I need to make it on another line 15:23:58 <frosch123> "{}" is linebreak 15:24:09 <V453000> :o 15:24:38 <frosch123> is that written nowhere? 15:25:10 <V453000> it is there 15:25:58 <V453000> OH I just misunderstood it 15:26:00 <V453000> .. :) 15:27:02 <frosch123> why does nml have a special code for {COPYRIGHT] ? 15:27:24 <frosch123> want to keep english in ascii? 15:28:46 <frosch123> or was someone annoyed about people not knowing about unicode and typinc "(C)" ? :p 15:29:05 <Rubidium> frosch123: because strgen has one? 15:29:34 <frosch123> hmm, ok, that is half an answer :p 15:31:56 <Hirundo> There's indeed a lot of copy-pasta from strgen 15:34:56 <planetmaker> One of the ideas was "what works in OpenTTD language files should also work in NML" 15:35:03 <planetmaker> or as much of that as possible 15:35:06 <planetmaker> and applicable 16:12:55 <Brot6> feed NewGRFs had 15 updates, showing the latest 10 16:12:56 <Brot6> Dutch Trains 2.0 - Feature #3383 (Closed): NS 2200 (foobar) @ http://dev.openttdcoop.org/issues/3383#change-9355 16:12:56 <Brot6> Dutch Trains 2.0 - Feature #3412 (Closed): ACTS 6700 (foobar) @ http://dev.openttdcoop.org/issues/3412#change-9358 16:12:56 <Brot6> Dutch Trains 2.0 - Feature #3402 (Closed): Class 66 (foobar) @ http://dev.openttdcoop.org/issues/3402#change-9357 16:12:56 <Brot6> Dutch Trains 2.0 - Feature #3393 (Closed): NS 2600 Beel (foobar) @ http://dev.openttdcoop.org/issues/3393#change-9356 16:12:59 <Brot6> Dutch Trains 2.0 - Feature #3427 (Closed): RN232 (foobar) @ http://dev.openttdcoop.org/issues/3427#change-9360 16:13:02 <Brot6> Dutch Trains 2.0 - Feature #3451 (Closed): Vossloh G2000BB (foobar) @ http://dev.openttdcoop.org/issues/3451#change-9361 16:13:05 <Brot6> Dutch Trains 2.0 - Feature #3555 (Closed): NS 2400 (foobar) @ http://dev.openttdcoop.org/issues/3555#change-9362 16:13:08 <Brot6> Dutch Trains 2.0 - Feature #3417 (Closed): MaK G 1206 (foobar) @ http://dev.openttdcoop.org/issues/3417#change-9359 16:13:11 <Brot6> Dutch Trains 2.0 - Feature #3585 (Closed): NS 6400 (foobar) @ http://dev.openttdcoop.org/issues/3585#change-9364 16:13:16 <Brot6> Dutch Trains 2.0 - Feature #3561 (Closed): ACTS 5800 (Class 58) (foobar) @ http://dev.openttdcoop.org/issues/3561#change-9363 16:31:04 *** andythenorth has joined #openttdcoop.devzone 16:32:50 <andythenorth> can nml accept arbitrary properties in an item block? 16:32:54 <andythenorth> or only known props? 16:34:01 <andythenorth> I don't want it to do anything with them right now 16:34:10 <andythenorth> it's just a matter of interest 16:39:06 <Brot6> Dutch Trains 2.0 - Feature #3617 (New): NS 1100 (Voyager1) @ http://dev.openttdcoop.org/issues/3617 16:42:41 <frosch123> andythenorth: of course only known ones 16:42:49 <frosch123> what would you expect it to do with unknown ones? 16:43:28 <frosch123> you know that ignoring unknown stuff can crash spaceships? 16:44:23 <andythenorth> it's not html then :P 16:44:33 <andythenorth> you can handily invent arbitrary attributes for html tags 16:44:40 <andythenorth> or tags themselves (in some cases) 16:44:51 <andythenorth> nvm 16:44:59 <andythenorth> makes no difference to what I'm doing 16:45:09 <andythenorth> but limits possibilities others might want to pursue 17:10:23 <Brot6> grfcodec: update from r856 to r857 done - http://bundles.openttdcoop.org/grfcodec/nightlies/r857 17:10:51 <Brot6> Dutch Trains 2.0 - Feature #3602: NS 1200 (Voyager1) @ http://dev.openttdcoop.org/issues/3602#change-9366 17:14:29 <Brot6> nml: update from r1792 to r1800 done - http://bundles.openttdcoop.org/nml/nightlies/r1800 17:19:43 <Brot6> ogfx-trains: update from r295 to r296 done - http://bundles.openttdcoop.org/ogfx-trains/nightlies/r296 17:25:27 <Brot6> cets: update from r566 to r575 done (377 warnings) - http://bundles.openttdcoop.org/cets/nightlies/r575 17:27:20 <Brot6> dutchtrains: update from r99 to r119 done - http://bundles.openttdcoop.org/dutchtrains/nightlies/r119 17:37:04 <Brot6> feed NewGRFs had 14 updates, showing the latest 10 17:37:04 <Brot6> Dutch Trains 2.0 - Revision 125:7e641937fcbc: Feature: NS450 (graphics by Voyager One) (closes #3... (foobar) @ http://dev.openttdcoop.org/projects/dutchtrains/repository/revisions/7e641937fcbc 17:37:04 <Brot6> Dutch Trains 2.0 - Revision 126:c2aa22103b34: Fix (r121, r122, r123, r124): use correct identifie... (foobar) @ http://dev.openttdcoop.org/projects/dutchtrains/repository/revisions/c2aa22103b34 17:37:04 <Brot6> Dutch Trains 2.0 - Revision 127:ae2e68704967: Feature: NS400 (graphics by Voyager One) (closes #3... (foobar) @ http://dev.openttdcoop.org/projects/dutchtrains/repository/revisions/ae2e68704967 17:37:08 <Brot6> Dutch Trains 2.0 - Feature #3434 (Closed): NS100 (foobar) @ http://dev.openttdcoop.org/issues/3434#change-9367 17:37:11 <Brot6> Dutch Trains 2.0 - Feature #3466 (Closed): NS 2801 (foobar) @ http://dev.openttdcoop.org/issues/3466#change-9369 17:37:14 <Brot6> Dutch Trains 2.0 - Feature #3457 (Closed): NS 2000 (foobar) @ http://dev.openttdcoop.org/issues/3457#change-9368 17:37:17 <Brot6> Dutch Trains 2.0 - Feature #3463 (Closed): NS 2900 (foobar) @ http://dev.openttdcoop.org/issues/3463#change-9370 17:37:20 <Brot6> Dutch Trains 2.0 - Feature #3468 (Closed): NS 450 (foobar) @ http://dev.openttdcoop.org/issues/3468#change-9372 17:37:25 <Brot6> Dutch Trains 2.0 - Feature #3493 (Closed): NedTrain Vossloh G400B (foobar) @ http://dev.openttdcoop.org/issues/3493#change-9371 17:37:28 <Brot6> Dutch Trains 2.0 - Feature #3483 (Closed): NS 400 (foobar) @ http://dev.openttdcoop.org/issues/3483#change-9373 17:40:34 *** andythenorth has quit IRC 17:43:23 *** andythenorth has joined #openttdcoop.devzone 18:12:01 <Brot6> ogfx-biggui: compile of r15 still failed (#3606) - http://bundles.openttdcoop.org/ogfx-biggui/nightlies/ERROR/r15 18:31:06 <Brot6> smts: rebuild of r19 done (Diffsize: 8) (DiffDiffsize: 19) - http://bundles.openttdcoop.org/smts/nightlies/r19/log 18:36:30 <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: bros (1 warnings), ogfx-industries (Diffsize: 114167), firs (6 warnings), opengfx (Diffsize: 7), foobarstramtracks (Diffsize: 37132), transrapidtrackset, 2cctrainset (78 warnings), bandit (1 warnings), worldairlinersset, heqs, basecosts, water-features, isr (2 warnings), 32bpp-extra (2 warnings), manindu (Diffsize: 2), newgrf_makefile (Diffsize: 12), 18:36:30 <Brot6> rust (Diffsize: 188), snowlinemod, dutchtramset, swisstowns (Diffsize: 43), metrotrackset (Diffsize: 1), dutchroadfurniture, spanishtowns (Diffsize: 8), frenchtowns (Diffsize: 21), ogfx-rv, fish, ogfx-landscape (2 warnings) (Diffsize: 828), ttrs (7 warnings), ogfx-trees, swedishrails, german-townnames (Diffsize: 51), chips (1 warnings), dach, belarusiantowns (Diffsize: 64), indonesiantowns (1 warnings) (Diffsize: 29), airportsplus 18:36:32 <Brot6> (Diffsize: 441059), comic-houses (3 warnings) (Diffsize: 22) 18:42:24 <V453000> is there some secret to note about the purchase menu sprites? With normal vehicles they work perfectly, but double headed vehicles seem to break very quickly - it looks like each "head" is there twice, in both directions, but they are each in a bit different position so the "middle" piece overlaps. What should I do when I want to overwrite the purchase menu sprite of a 2headed engine and prevent such issue? 18:42:28 <V453000> seen http://dl.dropbox.com/u/20419525/2headedbork.png 18:46:52 <andythenorth> V453000: you have a separate sprite for the purchase menu? 18:47:00 <andythenorth> the nml templates from foobar have a space for it 18:47:05 <andythenorth> in the trams example 18:47:27 <andythenorth> generally it's better to draw and code a specific sprite for purchase menu, to control position etc 18:47:39 <V453000> yes I have a separate image for the purchase menu sprites 18:48:07 <V453000> I have my own template that isnt a problem 18:48:31 <V453000> http://dl.dropbox.com/u/20419525/PurchaseMenu.png this is it 18:52:24 <Hirundo> multihead vehicles draw 2 sprites, using both _ views 18:52:54 <V453000> yeah exactly but is there any way how to go around that? 18:53:07 <V453000> or... how to make a "normally looking" purchase menu sprite 18:53:57 <Hirundo> easiest might be, to use an empty sprite for the second _ sprite 18:55:01 <V453000> I thought that too, but I define only one sprite at the moment for the purchase menu ... so should I define two while the 2nd is empty? 18:55:56 <Hirundo> your purchase spriteset currently only has one sprite? 18:56:41 <V453000> yes 18:57:30 <Hirundo> I'm not sure if two sprites 1 full 1 empty will work, though you can try 18:57:45 <V453000> trying now 18:58:45 <Brot6> Dutch Trains 2.0 - Revision 128:d7aee385feb1: Feature: new graphics for NS 1000 (by Voyager One) ... (foobar) @ http://dev.openttdcoop.org/projects/dutchtrains/repository/revisions/d7aee385feb1 18:58:45 <Brot6> Dutch Trains 2.0 - Feature #3584 (Closed): NS 1000 (foobar) @ http://dev.openttdcoop.org/issues/3584#change-9374 18:59:41 <Hirundo> else, put the full sprite in the normal <--- sprite slot, and empty ones in all others 19:00:30 <V453000> yeah, like normal 8 view template 19:00:44 <Hirundo> exactly 19:01:00 <V453000> the "cheat" with two didnt work :) 19:02:01 <Hirundo> I had expected that 19:04:11 <Brot6> Dutch Trains 2.0 - Revision 129:81b5bfcd4e92: Feature: new graphics for NS 1100 (by Voyager One) ... (foobar) @ http://dev.openttdcoop.org/projects/dutchtrains/repository/revisions/81b5bfcd4e92 19:04:11 <Brot6> Dutch Trains 2.0 - Feature #3617 (Closed): NS 1100 (foobar) @ http://dev.openttdcoop.org/issues/3617#change-9375 19:08:08 <andythenorth> dual headed trains are an articulated vehicle? or some other magic? 19:08:32 <V453000> no just dual_headed 19:08:37 <V453000> articulated is something else 19:08:46 <andythenorth> consist position isn't available in buy menu? 19:08:52 * andythenorth -> specs 19:09:21 <andythenorth> no 19:09:42 <V453000> Hirundo: it looks like a bloody hack, but it works like charm :D 19:11:07 <Hirundo> it's not a real hack 19:11:35 <Hirundo> do mind that the ---> sprite must be non-empty, so at least 1 blue pixel 19:12:50 <V453000> I have it full of blue pixels :) 19:12:54 <Hirundo> all others (except <--- of course) may be completely empty, i.e. [] in NML 19:13:07 <V453000> oh :) 19:13:26 <V453000> doesnt matter, I just defined 7 all-blue sprites in one corner of the image 19:13:30 <V453000> in the same posisiton 19:13:46 <Hirundo> that pixel will end up 7 times in the final grf 19:14:02 <Hirundo> what a waste of bytes ;-) 19:15:04 <Brot6> Dutch Trains 2.0 - Revision 130:0a5a99228dff: Feature: new graphics for NS 1200 (sprites by DanMa... (foobar) @ http://dev.openttdcoop.org/projects/dutchtrains/repository/revisions/0a5a99228dff 19:15:04 <Brot6> Dutch Trains 2.0 - Revision 131:194e36006c57: Feature: new graphics for NS 1300 (sprites by Basti... (foobar) @ http://dev.openttdcoop.org/projects/dutchtrains/repository/revisions/194e36006c57 19:15:04 <Brot6> Dutch Trains 2.0 - Feature #3602 (Closed): NS 1200 (foobar) @ http://dev.openttdcoop.org/issues/3602#change-9376 19:15:05 <Brot6> Dutch Trains 2.0 - Feature #3603 (Closed): NS 1300 (foobar) @ http://dev.openttdcoop.org/issues/3603#change-9377 19:15:59 <Brot6> Dutch Trains 2.0 - Feature #3566 (Feedback): NS 1500 (foobar) @ http://dev.openttdcoop.org/issues/3566#change-9378 19:16:32 <V453000> I already have a flood of unreferenced sprites :P 19:16:45 <Brot6> Dutch Trains 2.0 - Revision 132:b43ee13b67f5: Feature: new graphics for NS 1500 (by Voyager One) ... (foobar) @ http://dev.openttdcoop.org/projects/dutchtrains/repository/revisions/b43ee13b67f5 19:35:56 <Brot6> Dutch Trains 2.0 - Revision 133:a90f8cd6848d: Feature: new graphics for NS 1600P (sprites by Purn... (foobar) @ http://dev.openttdcoop.org/projects/dutchtrains/repository/revisions/a90f8cd6848d 19:35:56 <Brot6> Dutch Trains 2.0 - Revision 134:a2dd1e8ab25e: Feature: new graphics for HLE 25.5 (by Voyager One)... (foobar) @ http://dev.openttdcoop.org/projects/dutchtrains/repository/revisions/a2dd1e8ab25e 19:35:56 <Brot6> Dutch Trains 2.0 - Feature #3404 (Closed): NMBS Class 25.5 (foobar) @ http://dev.openttdcoop.org/issues/3404#change-9380 19:35:57 <Brot6> Dutch Trains 2.0 - Feature #3591 (Closed): 1600P (foobar) @ http://dev.openttdcoop.org/issues/3591#change-9379 19:44:53 <Brot6> GRFCodec - Revision 858:edf1461c4464: -Add: Action 2 railtype variable 44. (frosch) @ http://dev.openttdcoop.org/projects/grfcodec/repository/revisions/edf1461c4464 19:47:52 <Brot6> Dutch Trains 2.0 - Revision 135:0bdfa445de27: Feature: Plan mP (graphics by Voyager One) (closes ... (foobar) @ http://dev.openttdcoop.org/projects/dutchtrains/repository/revisions/0bdfa445de27 19:47:52 <Brot6> Dutch Trains 2.0 - Feature #3391 (Closed): Motorpostrijtuig mP (foobar) @ http://dev.openttdcoop.org/issues/3391#change-9381 20:11:18 <andythenorth> hm 20:11:33 <andythenorth> no compiled python bytes allowed on the devzone then :P 20:13:30 <andythenorth> fuck a doodle doo 20:13:48 <andythenorth> I've accidentally added a .pyc, then committed, then removed it, then committed 20:13:58 <andythenorth> which solves nothing wrt push being disallowed 20:14:04 <andythenorth> now I'm screwed :P 20:14:58 <andythenorth> help? :| 20:15:28 <Ammler> strip 20:16:26 <andythenorth> last time I stripped, I broke the remote repo 20:16:28 <Ammler> but you can always add your own hook ini, if you don't like the default 20:16:35 <Ammler> andythenorth: no 20:16:39 <Ammler> you didn't for sure 20:17:05 <Ammler> you are not able to strip on our server or do you have ssh access? 20:17:21 <andythenorth> I need to strip locally first no? 20:17:22 <Ammler> you should strip your broken local repo 20:17:26 <Ammler> yes 20:17:38 <andythenorth> it's not broken, it just disagrees with devzone 20:17:49 <Ammler> as your push failed, you don't need to strip on the server 20:17:52 <andythenorth> no 20:18:04 <andythenorth> but last time I stripped locally I created some horrible mess of heads 20:18:08 <andythenorth> you had to fix it for me 20:18:10 <Ammler> so just strip the changeset with the bad file 20:18:17 <andythenorth> ok 20:18:17 <Ammler> commit again and push 20:18:19 <andythenorth> let's see 20:19:22 *** ODM has quit IRC 20:19:59 <Ammler> andythenorth: for safety, pull & update before you commit and push 20:20:12 <andythenorth> ok 20:21:21 <andythenorth> stripped the offending rev 20:21:28 <andythenorth> this won't create multiple heads? 20:21:36 <Ammler> I wonder, if those python scripts from you and eddi aren't useable for makefile framwork 20:21:46 <andythenorth> Ammler: we'll see :) 20:21:48 <Ammler> andythenorth: pull and update before you commit again 20:21:57 <andythenorth> no changes found 20:22:08 <Ammler> then you didn't strip too much :-) 20:22:22 <Ammler> you can also check your local repo with graphlog 20:22:33 <Ammler> so you see, if you have ugly heads yourself 20:25:01 <andythenorth> oh how interesting 20:25:06 <andythenorth> the strip removed all my code :) 20:25:44 <andythenorth> that was undesirable 20:25:54 <andythenorth> that's 1 hour of work...missing :D 20:26:25 <Rubidium> doesn't strip make a backup? 20:27:44 <andythenorth> strip-backup? 20:27:46 <andythenorth> looks like it 20:27:52 <andythenorth> dunno how to unpack that though 20:30:08 <Ammler> unbundle 20:30:25 <andythenorth> ah 20:30:28 <andythenorth> there's my code :) 20:30:39 <Ammler> but well, it is obvious that strip removes the code, what did you expect? 20:30:54 <Ammler> I guess, there is an option to keep changes in workcopy 20:31:05 <andythenorth> I want to remove the commits, not the code :P 20:31:44 <Ammler> but unbundle did also restore the commit 20:31:48 <andythenorth> yup 20:31:55 <Ammler> just you know :-P 20:32:31 <Ammler> strip -k 20:32:32 <andythenorth> :) 20:32:54 <andythenorth> yay 20:32:58 <andythenorth> ammler \o/ 20:33:03 <andythenorth> [I think] 20:33:15 * andythenorth will eat dinner then try a commit again 20:33:45 <andythenorth> does devzone project stuff ship with default .hgignore set (I think it does?) 20:33:51 <Ammler> no 20:33:56 <andythenorth> oh 20:34:01 <Ammler> but I guess, teh makefile framwork has one 20:34:07 <andythenorth> it should add .pyc :P 20:34:08 <Ammler> but not pyc maybe 20:35:38 <Ammler> well, what would be cool it, if you could replace gcc with python 20:36:34 <Ammler> then only make needs to be replaced finally :-) 20:39:07 <andythenorth> Ammler: I meant the .hgignore should ignore *.pyc :) 20:39:13 <andythenorth> as devzone does not allow it to be pushed 20:41:18 <andythenorth> but also, yes, I'm replacing the use of c pre-processor entirely 20:56:19 <Brot6> Dutch Trains 2.0 - Bug #3618 (New): Wrong trains available for 3rd rail (Transportman) @ http://dev.openttdcoop.org/issues/3618 20:59:47 <andythenorth> Ammler: finally fixed (had to go back another rev) - thanks ;) 20:59:54 <andythenorth> hg st 21:00:15 <Brot6> BANDIT - Revision 136:5568290b9917: Change: rebuilding the build system (breaks the grf just a bi... (andythenorth) @ http://dev.openttdcoop.org/projects/bandit/repository/revisions/5568290b9917 21:01:54 <Brot6> Dutch Trains 2.0 - Feature Request #3619 (New): Parameter to set train names (Transportman) @ http://dev.openttdcoop.org/issues/3619 21:03:35 <Brot6> Dutch Trains 2.0 - Bug #3618: Wrong trains available for 3rd rail (Transportman) @ http://dev.openttdcoop.org/issues/3618#change-9382 21:04:26 <andythenorth> Ammler: BANDIT will for some time probably throw a lot of devzone compile errors 21:04:55 <andythenorth> also I've added a dep - python chameleon module 21:05:07 <andythenorth> I don't know how we tell devzone to build deps? 21:05:19 <andythenorth> easy_install Chameleon is straightforward 21:38:33 <andythenorth> Yexo: nml reports unexpected token 'visual_effect' for the following line: 21:38:37 <andythenorth> visual_effect: visual_effect(VISUAL_EFFECT_DIESEL, 0); 21:38:53 <Yexo> what is the line before that? 21:39:04 <andythenorth> a line missing it's ; 21:39:09 <Yexo> ;) 21:39:09 <andythenorth> :m 21:39:34 <andythenorth> needs better idiot-proofing 21:39:41 * andythenorth can supply hi-grade idiocy 21:40:16 <Yexo> it's quite hard to make better error messages for this 21:41:09 <andythenorth> I can imagine 21:44:57 <Brot6> Dutch Trains 2.0 - Revision 136:ab92f387c09e: Change: move metros to top of purchase list (foobar) @ http://dev.openttdcoop.org/projects/dutchtrains/repository/revisions/ab92f387c09e 21:46:08 <Brot6> Dutch Trains 2.0 - Bug #3618 (Rejected): Wrong trains available for 3rd rail (Transportman) @ http://dev.openttdcoop.org/issues/3618 21:46:08 <Brot6> Dutch Trains 2.0 - Bug #3618 (Rejected): Wrong trains available for 3rd rail (foobar) @ http://dev.openttdcoop.org/issues/3618#change-9383 21:47:13 *** LordAro has quit IRC 21:47:43 <Brot6> Dutch Trains 2.0 - Feature #3619 (New): Parameter to set train names (Transportman) @ http://dev.openttdcoop.org/issues/3619 21:47:43 <Brot6> Dutch Trains 2.0 - Feature #3619: Parameter to set train names (foobar) @ http://dev.openttdcoop.org/issues/3619#change-9384 21:54:32 <andythenorth> ho ho ho 21:55:44 <Brot6> BANDIT - Revision 137:f2f39da80f02: Change: python build system works \oo/ (andythenorth) @ http://dev.openttdcoop.org/projects/bandit/repository/revisions/f2f39da80f02 21:59:31 <andythenorth> Yexo: do you have any plans to add built-in templating to nml (and if so, can I persuade you otherwise?) :) 22:01:24 *** orudge has quit IRC 22:01:24 *** Rubidium has quit IRC 22:03:07 *** orudge has joined #openttdcoop.devzone 22:03:07 *** Rubidium has joined #openttdcoop.devzone 22:26:21 <Brot6> BANDIT - Revision 138:e8e51f1b54b6: Codechange: provide for vehicles using multiple templates (andythenorth) @ http://dev.openttdcoop.org/projects/bandit/repository/revisions/e8e51f1b54b6 22:37:04 <Brot6> BANDIT - Revision 139:73b29fe52efb: Change: start scaffolding for trailers (andythenorth) @ http://dev.openttdcoop.org/projects/bandit/repository/revisions/73b29fe52efb 22:56:15 *** LordAro has joined #openttdcoop.devzone 23:25:24 <Brot6> Central European Train Set - Feature #3620 (New): Force 32bpp (oberhuemer) @ http://dev.openttdcoop.org/issues/3620 23:26:07 <Brot6> Central European Train Set - Feature #3620 (New): Force 32 bpp (oberhuemer) @ http://dev.openttdcoop.org/issues/3620 23:35:16 *** LordAro has quit IRC 23:42:12 *** frosch123 has quit IRC 23:42:37 *** frosch123 has joined #openttdcoop.devzone 23:44:54 <Brot6> Central European Train Set - Feature #3620 (New): Force 32 bpp (oberhuemer) @ http://dev.openttdcoop.org/issues/3620 23:52:06 <Brot6> BANDIT - Revision 140:2d425fc08716: Change: provide stub objects for trailers (andythenorth) @ http://dev.openttdcoop.org/projects/bandit/repository/revisions/2d425fc08716 23:53:00 <Yexo> andythenorth: I have no plans to built-in more templating in nml, there are enough fine tools for that already 23:53:08 <andythenorth> \o/ 23:53:26 <andythenorth> templating would be fine, but I think you'd be wasting valuable dev time ;) 23:53:28 <Yexo> the only thing I might do is add support for including other files 23:53:37 <andythenorth> that seems sane 23:54:11 <andythenorth> Ammler: did you see my query about python chameleon as a dep. for building BANDIT on devzone? 23:55:21 <andythenorth> Yexo: it's quite interesting to construct a python obj. for each vehicle 23:55:29 <andythenorth> and then create a render method 23:55:32 <andythenorth> it's very clean 23:55:57 <Yexo> does it make the code easier to read? 23:56:13 <andythenorth> depends on what you're used to 23:56:32 <andythenorth> I'm used to reading python + html mixed in with $ and xml-style templating 23:57:34 <andythenorth> here's my build script (unfinished) http://paste.openttdcoop.org/show/992/ 23:57:43 <andythenorth> and here's the main vehicle template http://paste.openttdcoop.org/show/991/ 23:57:57 <andythenorth> there's other stuff, but it's quite accessible I hope 23:58:07 <Brot6> OpenGFX - Bug #3222: alignment of trains (frosch) @ http://dev.openttdcoop.org/issues/3222#change-9387 23:58:23 <Ammler> andythenorth: query? 23:58:33 <Ammler> I have no query here 23:58:46 <andythenorth> nvm :) 23:59:04 <andythenorth> but how do I install a dep. on the devzone? 23:59:13 <Ammler> you can basically have everything 23:59:30 <Ammler> if not available, we can build it 23:59:43 <Ammler> like e.q. we create nml-dot-wine 23:59:45 <andythenorth> for me it was easy_install Chameleon 23:59:47 <Yexo> SOUND_TRUCK_START_2; //cpp constant <- actually that is an nml constant 23:59:54 <andythenorth> ho 23:59:56 <andythenorth> code review :)