Times are UTC Toggle Colours
01:14:11 *** Sylf has quit IRC 05:50:12 *** andythenorth has joined #openttdcoop.devzone 06:29:22 <Brot6> FIRS Industry Replacement Set - Feature #2996: Split cargo label for Sugar Cane / Sugar Beet (andythenorth) @ http://dev.openttdcoop.org/issues/2996#change-7570 06:33:34 * andythenorth ponders trying some nml 06:33:35 <andythenorth> :o 06:35:57 * andythenorth will have questions 06:36:38 <V453000> I dont think you are going to have more questions than me :P 06:37:28 <andythenorth> action 1: there are bits missing 06:37:35 <andythenorth> where did the crops go? 06:38:05 <andythenorth> or is it the offsets that are gone? 06:38:12 <andythenorth> the offsets are in the adv action 2? 06:38:19 * andythenorth is confused 06:42:11 <andythenorth> so I could name the spriteset blocks? 06:42:25 <andythenorth> instead of 'spriteset_x' it could be 'spriteset_conesilo' 06:42:34 <andythenorth> more self documenting 07:01:36 <Brot6> FIRS Industry Replacement Set - Revision 2498:ba443ab542ff: Feature: revamped Sugar Refinery - im... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/ba443ab542ff 07:01:36 <Brot6> FIRS Industry Replacement Set - Feature #2413 (Closed): Improve Sugar Refinery graphics + layouts (andythenorth) @ http://dev.openttdcoop.org/issues/2413#change-7571 07:08:42 <Brot6> FIRS Industry Replacement Set - Feature #2726 (Rejected): Control CC for Sugar Refinery (andythenorth) @ http://dev.openttdcoop.org/issues/2726#change-7572 07:13:18 <Brot6> FIRS Industry Replacement Set - Revision 2499:f85fc95b2b56: Cleanup: remove un-needed pcx file (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/f85fc95b2b56 07:16:01 <andythenorth> hmm 07:16:33 <andythenorth> planetmaker / Terkhen I was going to update the sprites / layouts for recycling plant, but I don't know if it's templated yet 07:16:44 <andythenorth> it looks different to sugar refinery 07:17:09 <andythenorth> sugar refinery was mostly self-explanatory 07:20:00 <Ammler> \o/ andythenorth does touch firs code again :-) 07:20:57 <planetmaker> both industries seem templated to me 07:21:14 <andythenorth> maybe it's the switch for layouts that's confusing me 07:21:29 <andythenorth> yeah 07:21:37 <andythenorth> sugar refinery uses relative_coord 07:21:40 <andythenorth> is that a macro? 07:22:06 <andythenorth> recycling plant uses some ints which presumably encode the offsets 07:25:33 <planetmaker> spriteset(THIS_ID(spriteset_1), "sprites/graphics/industries/recyclingplant.pcx") { tmpl_building_sprite(10, 10, 76, -45) } <-- x,y, height, y-offset 07:29:01 <planetmaker> check out the template for the meaning of its parameters 07:29:59 <andythenorth> and the layout switch? 07:30:06 * andythenorth should just read the nml manual 08:00:17 <andythenorth> hmm 08:01:14 <planetmaker> recycling plant has no layout switch as it only has one layout 08:01:45 <andythenorth> it's the switch for tiles that I refer to 08:01:45 <andythenorth> switch(FEAT_INDUSTRYTILES, SELF, THIS_ID(layout), relative_pos) { 08:01:48 <andythenorth> my bad 08:04:01 * andythenorth has it figured - probably 08:05:10 <andythenorth> btw my experience is that it's always safer to use position 0 for ground tile 08:05:24 <andythenorth> then if appending further sprites, they don't have to be re-ordered 08:25:06 <Brot6> FIRS Industry Replacement Set - Revision 2500:8a61b0e08397: Feature: revamped graphics and layout... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/8a61b0e08397 08:25:06 <Brot6> FIRS Industry Replacement Set - Feature #2741 (Closed): Finish reworking Recycling Plant graphics... (andythenorth) @ http://dev.openttdcoop.org/issues/2741#change-7573 08:28:43 <Brot6> FIRS Industry Replacement Set - Code Review #2495 (Rejected): Colours of recycling plant (andythenorth) @ http://dev.openttdcoop.org/issues/2495#change-7574 08:28:43 <Brot6> FIRS Industry Replacement Set - Revision 2501:ef77b6e0e158: Change: remove un-needed pcx file (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/ef77b6e0e158 08:29:06 <andythenorth> 6 tickets remaining 08:29:19 <Rubidium> woohoo ;) 08:30:14 <andythenorth> after that, only another 78 in the issue tracker :P 08:35:36 <Brot6> GRFCodec - Bug #1568 (Closed): Search for nforenum or grfcodec (Rubidium) @ http://dev.openttdcoop.org/issues/1568#change-7575 08:37:02 <Ammler> Rubidium: orudge might have access there too 08:37:07 <Ammler> at least on the userpage 08:38:32 <Rubidium> I would see that as a breach of trust 08:39:01 <Rubidium> I really wouldn't want my ISP to change my site without my consent 08:40:06 <Ammler> well, that is not your concern, you always think for others :-P 08:41:01 <Ammler> if the owner has changed, an ISP should move the domain 08:41:07 <Ammler> well, the isp does 08:41:22 <Ammler> already did such things... 08:42:10 <Ammler> but in the meantime, those urls are forgotten anyway... 08:49:27 <Brot6> FIRS Industry Replacement Set - Bug #3003 (New): Change min compatible version prior to release /... (planetmaker) @ http://dev.openttdcoop.org/issues/3003 08:51:04 <Rubidium> and back to 7? 08:51:24 <andythenorth> meh 08:52:42 <Ammler> we really should add openttd to check, so we find the exact uncompatible version :-) 08:54:45 *** ODM has joined #openttdcoop.devzone 09:13:03 <Brot6> FIRS Industry Replacement Set - Revision 2502:6e08f596bf13: Cleanup: remove un-needed pcx (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/6e08f596bf13 09:15:58 <Brot6> FIRS Industry Replacement Set - Revision 2503:3ee6e4bc38f1: Change: add building snow to Glass Works (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/3ee6e4bc38f1 09:16:07 <andythenorth> planetmaker: ^ I haven't added the ground snow to that one 09:16:20 <andythenorth> not yet 100% sure how you would like it done 09:47:05 <Terkhen> I'm going to check the grain mill now 10:07:16 <planetmaker> andythenorth: the same way as builder's yard 10:07:20 <planetmaker> quite straight forward 10:07:38 <andythenorth> planetmaker: should the ground snow be in a separate file though? 10:07:50 <planetmaker> I don't care and it doesn't matter 10:08:13 <planetmaker> you need to just define it as a spriteset which can be used - where the graphcis are... who cares? ;-) 10:08:39 <planetmaker> my whole argument was only: snow ground should only show the difference to default snow 10:08:46 <andythenorth> the ground snow in a separate spriteset? 10:08:54 * andythenorth kind of follows, but wants to be sure 10:09:17 <planetmaker> ttd snow sprite is used on snow as ground 10:09:28 <planetmaker> and then the "user - supplied" ground is drawn over it 10:09:32 <planetmaker> which is what you draw 10:09:43 <andythenorth> hmm 10:09:49 <andythenorth> so it needs to be in a separate png 10:09:58 <planetmaker> why? 10:09:59 <andythenorth> for management purposes, not coding 10:10:07 <andythenorth> you need it separate from the building 10:10:12 <andythenorth> so it has to be....separate 10:10:17 <planetmaker> it just needs to be a separate sprite 10:10:20 <planetmaker> not png 10:10:49 <planetmaker> you you manage that with the sprites is up to you. I don't really care 10:11:35 <planetmaker> what we talked about the other day was only about how it could easily done in a layered fashion, thus streamline / reduce required work and splitting and stuff 10:11:55 <planetmaker> but you do there what you like as it's what you have to do anyway 10:12:24 <andythenorth> it demands an extra png I think 10:12:29 <andythenorth> can't think of another way to do it 10:12:58 <planetmaker> only important: we need always: ground overlay, ground including snow. building. building snow overlay 10:13:28 <Terkhen> http://paste.openttdcoop.org/show/512/ <--- can I use multiple variables in a single switch this way? the code compiles but it does not work as I expected (I'm currently checking the 0..1870 part of the switch and all layouts appear) 10:13:34 <andythenorth> building snow overlay without the building? 10:14:07 <planetmaker> doesn't matter really, I think. I'm not sure now 10:15:00 <andythenorth> might leave it until we're sure 10:15:10 <planetmaker> Terkhen: order of operators maybe? () around everything which needs returning? 10:15:12 <planetmaker> not sure though 10:15:29 <Terkhen> ah, that might be my problem 10:15:34 <planetmaker> andythenorth: conceptually IMHO the nicer way is to just draw snow as overlay. Always 10:15:36 <Terkhen> I had problems with that before too :P 10:16:20 <andythenorth> hmm 10:16:30 <andythenorth> we could make the xxx_snow.png like this: 10:16:34 <andythenorth> copy the non-snow 10:16:38 <andythenorth> paste the snow layer 10:16:43 <andythenorth> no that won't work 10:16:49 <andythenorth> maybe this 10:16:55 <andythenorth> duplicate the non-snow png 10:16:59 <andythenorth> convert to rgb 10:17:02 <andythenorth> paste snow 10:17:05 <andythenorth> align to building 10:17:31 <andythenorth> use marquee to remove building pixels from all blue bounding boxes 10:17:33 <andythenorth> index 10:17:34 <andythenorth> save 10:18:32 <planetmaker> sounds terribly complicated when compared to "draw snow on separate layer, done" 10:19:20 <andythenorth> I can't think of an easy way to do that 10:19:32 <andythenorth> it's a remarkably difficult problem 10:19:46 <andythenorth> maybe I could create slices and use a photoshop action to assemble them into the psds 10:19:57 <andythenorth> but that means maintaining a different action for each psd 10:20:04 <andythenorth> and actions are quite fragile 10:25:44 <Hirundo> Terkhen: AFAIK the posted code should work, adding parentheses would be a no-op as "return <expr>;" always eats the whole expression 10:26:21 <Terkhen> I think that it might have something to do with the templates that are called before my code 10:27:15 <Terkhen> planetmaker: http://devs.openttd.org/~terkhen/patches/index.php?source=firs/grain_mill.diff <-- with this diff, I can still place grain mills... I expected no grain mills at all 10:29:19 <Terkhen> oh 10:29:38 <Terkhen> CHECK_FOUNDER returns CB_RESULT_IND_ALLOW_LOCATION if the industry is being created manually 10:29:45 <Terkhen> I'll need to hook my code before it then 10:34:26 <planetmaker> yup, unconditional placement checks have to be before the founder check 10:34:33 <planetmaker> often it's the first one, but not always. 10:34:40 <planetmaker> E.g. water checks usually go before that 10:35:21 <planetmaker> Many placement restrictions apply to the game only, though and thus the user can circumvent it. 10:36:33 <planetmaker> anyway... off to canoeing tour :-) 10:36:42 <Terkhen> enjoy ;) 10:37:34 <andythenorth> canoeing industry! 10:39:22 <Hirundo> feature request: A canoe in FISH ;) 10:39:28 <Hirundo> enjoy pm :) 10:45:38 <Terkhen> heh 10:45:42 <Terkhen> I realized the problem now 10:45:59 <Terkhen> the layout_num var is not available during the location_check callback 10:46:25 <Terkhen> it seems to be located at 0x86 instead of at 0x44 10:46:40 <andythenorth> hmm 10:47:01 <andythenorth> it's certainly possible within the nfo spec, I wrote test code against the ottd patch that enabled this 10:47:28 <Terkhen> yes, but maybe nml is not taking care of the variable number change for me 10:51:13 <Hirundo> no, it is not 10:52:05 <Hirundo> For now, var[0x86] is your best bet 10:53:00 <Hirundo> In the future handling of variable scopes will likely change as http://wiki.openttd.org/Frosch/Secondary_Related_Objects comes along 10:53:54 <Terkhen> oh, thanks, I was testing with 0x86 but missing the var[ ] :) 10:55:56 <Hirundo> I could do a quick hack, but it's probably best to avoid that as FIRS is currently the only user in this area anyways 10:56:25 <Terkhen> I agree 10:59:00 <Yexo> Hirundo: I don't see how that proposal from frosch changes anything for this case 10:59:13 <Yexo> what we need here is a special variable list that is only used for a single callback 10:59:43 <Hirundo> Frosch's proposal will make the scope::var syntax even more useful 11:00:23 <Yexo> sure, but that doesn't change that the industry:: (or self::) scope has to contain different variables in that one callback than for all other industry callbacks 11:00:33 <Yexo> you can't change that without breaking backwards compatibility 11:00:37 <Hirundo> I'd create a special scope in this case (location_check::var) 11:00:45 <Yexo> ah, ok 11:01:12 <Hirundo> So each callback would get a list of available scopes (also needed for the trigger-specific 5th object) 11:01:30 <Hirundo> Also, you could verify no one is doing bad stuff in the purchase list, etc 11:02:23 <Yexo> ok, lot's of work coming up :p 11:02:45 <Hirundo> For now it's all 'future music' (as the Dutch expression) 11:02:59 <Yexo> yes, indeed 11:06:23 <Terkhen> in this specific case, layout_num != cb28 var[0x86]; layout_num starts at 1 and var[0x86] starts at 0 11:06:32 <Terkhen> finally it seems to be working 11:09:40 <Yexo> that's something we'd normally hide in nml 11:09:40 <Yexo> ie the future location_check::layout_num would also start at 1 11:10:30 <Terkhen> ok :) 11:21:54 <Brot6> FIRS Industry Replacement Set - Revision 2504:1d762c00dbee: Change #476: Limit the Grain Mill lay... (Terkhen) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/1d762c00dbee 11:22:00 <andythenorth> ooh 11:22:01 <Terkhen> andythenorth: ^ <-- I did not change the probabilities of the windmill after 1900 (during map generation); it has a 1/6 probability already and I think that is enough 11:22:15 * andythenorth tests 11:22:21 <planetmaker> +CHECK_INCOMPATIBLE (grain_mill, 56, CB_RESULT_IND_DISALLOW_UNSUITABLE, return CB_RESULT_IND_DISALLOW_UNSUITABLE) <-- Terkhen, the last location check has to allow at least one of the choices. 11:22:32 <planetmaker> But probably you have a solution for grain mill meanwhil. 11:22:56 <Terkhen> planetmaker: that's what I thought, but grain mills appeared anyways; the cause was the CHECK_FOUNDER template :) 11:23:05 <planetmaker> yup, ok :-) 11:23:19 <Terkhen> I just switched the code before CHECK_FOUNDER instead of at the end of the chain 11:23:32 <Terkhen> I also did not see any proper way to template the code, it seems too specific to me 11:24:05 <Brot6> FIRS Industry Replacement Set - Feature #476 (Closed): Windmill variation for Grain Mill (Terkhen) @ http://dev.openttdcoop.org/issues/476#change-7576 11:25:02 <andythenorth> Terkhen: awesome 11:25:13 <Terkhen> :) 11:25:23 <Terkhen> what other task of the code category should I do? 11:27:28 <planetmaker> Terkhen: usually i'd put that in the tile location rather than industry location code 11:27:45 <planetmaker> tile location code already checks for water (in some cases) 11:28:30 <planetmaker> but maybe you added it there... I read too briefly really 11:28:48 <Terkhen> but this code is related to the industry, not to the tiles 11:29:39 <Terkhen> hmmm... what this code does is "limit some layouts to some dates" 11:29:42 <Terkhen> nothing related to water 12:08:43 <Brot6> FIRS Industry Replacement Set - Feature #2821: Snow graphics for Glass Works (andythenorth) @ http://dev.openttdcoop.org/issues/2821#change-7577 12:11:04 <Brot6> FIRS Industry Replacement Set - Revision 2505:0d9886f3c26d: Change: add building snow to brick Gr... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/0d9886f3c26d 12:11:04 <Brot6> FIRS Industry Replacement Set - Feature #2755: Grain Mill snow sprites need finishing (andythenorth) @ http://dev.openttdcoop.org/issues/2755#change-7578 12:11:19 <andythenorth> Terkhen: I've run out of tickets that I can do 12:11:29 <Brot6> FIRS Industry Replacement Set - Bug #3003: Change min compatible version prior to release / branch (andythenorth) @ http://dev.openttdcoop.org/issues/3003#change-7579 12:11:42 <Terkhen> so... any code task? 12:11:44 <andythenorth> #2986 ? 12:11:44 <Brot6> andythenorth: #2986 is http://dev.openttdcoop.org/issues/show/2986 "FIRS Industry Replacement Set - Code Review #2986: Merge tiles of industries with more than one tile(?) - #openttdcoop Development Zone" 12:11:52 <andythenorth> and #2996 12:11:52 <Brot6> andythenorth: #2996 is http://dev.openttdcoop.org/issues/show/2996 "FIRS Industry Replacement Set - Feature #2996: Split cargo label for Sugar Cane / Sugar Beet - #openttdcoop Development Zone" 12:14:51 <Terkhen> IMO 2986 has a prerrequisite 12:15:01 <Terkhen> defining common spritesets for all ground sprites 12:15:34 <Terkhen> common industry tiles might not make sense, on the other hand common spritesets would allow to remove a lot of spriteset definitions 12:16:00 <Terkhen> but to make common spritesets, we need a way to ignore the "all spritesets in the same spritelayout must have the same size" restriction 12:16:15 <andythenorth> if the case is as I understand it, some of the tiles are redundant. The common spritesets might be unrelated to this issue? 12:22:55 <Terkhen> maybe, but IMO it would make sense to do both at the same time 12:22:59 <Terkhen> they are related enough for that 12:23:00 <andythenorth> maybe 12:23:05 <andythenorth> I don't really understand this code 12:23:13 <andythenorth> everything is a macro :o 12:23:15 <Terkhen> which code? 12:23:19 <andythenorth> most of it :) 12:23:37 <Terkhen> but what part of the code? 12:23:57 <andythenorth> the spritelayout code 12:24:05 <andythenorth> specifically wrt advanced varaction 2 12:24:21 <andythenorth> oosp 12:24:26 <andythenorth> advanced tile layouts I mean 12:24:44 <andythenorth> I would merge the tiles first personally 12:24:54 <andythenorth> on the basis of 'make one change at once' for reduced bugs 12:26:25 <Terkhen> SPRITELAYOUT_NORMAL_SNOW for example, receives two different ground sprites (first one is "normal", the second one is "snow), a spriteset and a zextent 12:26:34 <Terkhen> the spriteset contains the building sprites 12:26:47 <Terkhen> the first sprite in the sprite set is used for the normal building, the second one for the snow building 12:26:54 <Terkhen> each building is hidden conditionally depending on terrain type 12:27:13 <andythenorth> and all of the varaction 2s for that are templated? 12:27:13 <Terkhen> for ground sprites, the normal one is used as a real ground sprite, the snow sprite is a childsprite which is also hidden conditionally 12:27:50 <Terkhen> no 12:28:06 <Terkhen> each one of the spritelayouts defined are used by the relative_pos switches 12:28:16 <andythenorth> oh 12:28:17 <Terkhen> depending on the position of the tile, a different spritelayout is used 12:28:25 <andythenorth> I won't understand it until I code it :| 12:28:26 <andythenorth> ;) 12:28:47 <Terkhen> relative_coord(0, 2): THIS_ID(spritelayout_concrete); <--- if tile is in 0, 2, use the spritelayout_concrete spritelayout 12:29:03 <Terkhen> those switches are named THIS_ID(layout_x) 12:29:12 <Terkhen> and all of them are called from the THIS_ID(layout) switch 12:29:23 <Terkhen> which decides what switch to use depending on the current layout 12:29:45 * Terkhen wonders what is GROUNDSPRITE_SWITCH 12:30:24 <Terkhen> oh, it seems to be that fancy code to use gradual snow / desert 14:06:36 <orudge> Ammler: access to what? As a rule, I wouldn't modify a user's site without their permissions. users.tt-forums.net pages may be slightly different as they're provided for free, but I'd only do so with a very good reason. 14:10:25 <Rubidium> orudge: Dale's old nforenum site 14:12:53 <Rubidium> it's somewhat very outdated, but comes up pretty early in google searches 14:13:36 <orudge> Ah. 14:14:01 <orudge> Well, he's still active on the forums, I'm sure one could send a PM to him and ask him either to update it or to give me permission to update it 14:23:29 <Ammler> orudge: not just that page, also the one at ttdpatch.net 14:23:45 <orudge> ah, well, ttdpatch.net is obviously not under my control 14:24:10 <Ammler> well, you wouldn't do anything also if it were :-P 14:24:16 <orudge> yeah 14:24:18 <Ammler> so does not really matter :-) 14:26:47 <Ammler> but the final result is that nobody does anything and blames the other 14:28:30 <Brot6> DictatorAI - Revision 158:f0a5161764dc: ... (krinn) @ http://dev.openttdcoop.org/projects/ai-dictator/repository/revisions/f0a5161764dc 14:59:02 *** FooBar has joined #openttdcoop.devzone 15:30:46 *** Webster has joined #openttdcoop.devzone 15:30:48 *** XeryusTC has joined #openttdcoop.devzone 15:30:48 *** V4530000 has joined #openttdcoop.devzone 15:31:11 *** Yexo has joined #openttdcoop.devzone 15:31:26 *** avdg has joined #openttdcoop.devzone 15:31:28 *** V4530000 is now known as V453000 15:31:56 *** DJNekkid has joined #openttdcoop.devzone 15:32:14 *** planetmaker has joined #openttdcoop.devzone 15:36:28 <FooBar> hey, everyone is back :) 15:37:24 <FooBar> I asked a question right before you all timed out, so I'll ask it again :P 15:37:26 <FooBar> I have a question about the new style NML callbacks 15:37:28 <FooBar> How can I for instance have the vehicle capacity callback for the regular vehicle, but /not/ in the purchase menu? 15:37:29 <FooBar> If I use only the cargo_capacity callback, it automatically also applies to the purchase menu 15:37:31 <FooBar> If I add the purchase_cargo_capacity callback, I can't have a total capacity of 103 for a three-part articulated vehicle (as the position_in_consist variable is not available in the purchase menu) 15:38:09 <FooBar> Or alternatively, how can I not have the articulated vehicle callback in the purchase menu? 15:44:38 <Brot6> North American Road Vehicle Set - Revision 41:6a1a0d32d3ba: moved rest of trams to templates, fix... (oberhuemer) @ http://dev.openttdcoop.org/projects/narvs/repository/revisions/6a1a0d32d3ba 15:47:54 <Brot6> narvs: compile of r41 still failed (#2983) - http://bundles.openttdcoop.org/narvs/nightlies/ERROR/r41 15:52:19 <Brot6> North American Road Vehicle Set - Revision 42:6cc99310d654: re-added missing files (oberhuemer) @ http://dev.openttdcoop.org/projects/narvs/repository/revisions/6cc99310d654 15:54:15 <Brot6> North American Road Vehicle Set - Bug #2983 (Closed): DevZone compile failed (oberhuemer) @ http://dev.openttdcoop.org/issues/2983#change-7580 15:54:15 <Brot6> North American Road Vehicle Set - Bug #3004 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/3004 16:03:49 <Brot6> North American Road Vehicle Set - Revision 43:ac671513d886: Vehicle properties should be entered ... (oberhuemer) @ http://dev.openttdcoop.org/projects/narvs/repository/revisions/ac671513d886 16:04:51 <Brot6> North American Road Vehicle Set - Bug #3004 (Closed): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/3004 16:04:51 <Brot6> North American Road Vehicle Set - Bug #3004 (Closed): DevZone compile failed (oberhuemer) @ http://dev.openttdcoop.org/issues/3004#change-7581 16:06:11 <Brot6> North American Road Vehicle Set - Bug #3005 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/3005 16:08:31 *** Lakie has joined #openttdcoop.devzone 16:09:05 <Hirundo> FooBar: good question 16:09:05 <Brot6> North American Road Vehicle Set - Feature #3006 (New): Set cargo_age_period (oberhuemer) @ http://dev.openttdcoop.org/issues/3006 16:09:13 <FooBar> I thought so :P 16:09:48 <FooBar> It worked brilliantly with the old style callbacks 16:09:51 <Hirundo> the articulated parts callback is intentionally not available as a separate CB in the purchase menu 16:10:16 <FooBar> that is fine, but a means to explicitly disable that callback in the purchase menu would be nice 16:10:29 <Hirundo> Since creating a different amount of parts in the purchase menu and when actually building the vehicle is an error 16:10:43 <FooBar> wait... 16:10:50 <Hirundo> e.g. if the vehicle pool is exhausted, vehicle building will fail halfway 16:11:04 <FooBar> hmmm 16:11:14 <Hirundo> or if the articulated parts carry different cargos, you get strange results as well 16:11:43 <FooBar> so basically not having the articulated callback in the purchase menu (which I had so far with the old style callbacks) is wrong 16:12:22 <Hirundo> Yes, although you'll get away with it if all parts have the the same refit mask and/or carry no cargo 16:12:52 <Brot6> NewGRF Meta Language - Bug #3007 (New): Assertion error with NARVS (oberhuemer) @ http://dev.openttdcoop.org/issues/3007 16:12:55 <FooBar> I've been getting away with that ever since the first version of the Dutch tram set :P 16:13:28 <Brot6> NewGRF Meta Language - Bug #3007: Assertion error with NARVS (Hirundo) @ http://dev.openttdcoop.org/issues/3007#change-7582 16:13:49 <FooBar> But if you want to do it "right", this just means that the total vehicle capacity needs to be a multiple of the amount of articulated parts 16:14:25 <FooBar> And NML not allowing to do it "wrong" is good IMO 16:14:37 <Hirundo> What are the (intended) capacities of all parts? 16:14:47 <FooBar> 38, 27 and 38, total 103 16:14:55 <FooBar> I can paste you the code if you want 16:15:29 <FooBar> http://paste.openttdcoop.org/show/514/ 16:15:45 <Hirundo> you could use a different vehicle ID for both parts, or just for the middle part 16:16:57 <FooBar> well yes, but I don't really care if the capacity is 102 or 103 if not having the articulated callback in purchase is wrong 16:17:24 <FooBar> It still would be nice not to have the cargo capacity callback in purchase 16:17:44 <FooBar> That way purchase can use the cargo capacity property (set to total/#parts) 16:18:55 <Hirundo> what happens when the purchase cargo capacity is set to CB_FAILED; ? 16:19:28 <FooBar> didn't work without a separate switch, but with a separate switch it ended up using the capacity property 16:20:00 <Hirundo> only for the first part, or for all parts? 16:20:29 <FooBar> for all parts. I had the property set to 103, the menu displayed a capacity of 309 16:21:28 <FooBar> IMO, the ideal solution would be something like purchase_cargo_capacity: DISABLE; in the graphics block 16:21:48 <Hirundo> CB_FAILED should do just that 16:21:54 <Hirundo> if it doesn't, it's a bug 16:22:17 <FooBar> I couldn't use CB_FAILED there (Unknown identifier encountered) 16:22:29 <Hirundo> Then file a bug report :) 16:22:47 <FooBar> But then NML still adds an unnecessary callback to the purchase menu callback chain, right? 16:23:35 <Ammler> Hirundo: http://bundles.openttdcoop.org/narvs/nightlies/ERROR/r43/ 16:23:41 <Hirundo> It first splits between purchase and non-purchase via action3 16:23:59 <FooBar> yes 16:24:10 <Hirundo> Then it does a switch(current_callback) to select between the various callbacks 16:24:19 <FooBar> also what I thought 16:24:36 <Hirundo> In the case of CB 36, it then adds another switch(prop_nr) 16:24:57 <Hirundo> CB_FAILED is just a callback result of \w0, as action2 id 0 is never used in NML 16:25:23 <FooBar> and then in this particular case it adds a switch that always returns CB_FAILED. Which IMO sounds like you shouldn't have that switch in the first place 16:25:45 <Yexo> FooBar: everywhere you would use CB_FAILED you can instead use the spritegroup identifier of the real graphics 16:26:22 <Hirundo> it should output switch_spriteset_htm_4001 in the default case, as all unhandled callbacks should chain there 16:27:35 *** frosch123 has joined #openttdcoop.devzone 16:27:38 <Yexo> Which IMO sounds like you shouldn't have that switch in the first place <- true, but that's just an optimization we can still do at any point in the future 16:28:11 <FooBar> still, the decision based on (current_callback == VEH_CB_VEHICLE_PROPERTIES) and (extra_callback_info1 == cargo_capacity ) is completely unnecessary 16:28:30 <FooBar> in case it always returns CB_FAILED for the purchase menu 16:28:42 <FooBar> Yexo: yes, that's what I meant 16:28:56 <Brot6> North American Road Vehicle Set - Revision 44:3884fb6c1097: Some non-city buses were using the wr... (oberhuemer) @ http://dev.openttdcoop.org/projects/narvs/repository/revisions/3884fb6c1097 16:29:06 <Brot6> NewGRF Meta Language - Bug #3007: Assertion error with NARVS (oberhuemer) @ http://dev.openttdcoop.org/issues/3007#change-7583 16:30:25 <Brot6> FIRS Industry Replacement Set - Bug #3003: Change min compatible version prior to release / branch (planetmaker) @ http://dev.openttdcoop.org/issues/3003#change-7584 16:30:58 <FooBar> But yes, allowing return CB_FAILED from the graphics block would be a start I think. If the rest of it is considered "future optimization", then I'm fine with that. 16:31:26 <Yexo> instead of CB_FAILED you can (for now) just use the spritegroup_id there 16:31:30 <Yexo> the result will be the same 16:31:59 <Brot6> narvs: compile of r44 still failed (#3005) - http://bundles.openttdcoop.org/narvs/nightlies/ERROR/r44 16:33:54 <Brot6> NewGRF Meta Language - Bug #3008 (New): cannot use return CB_FAILED; in graphics block callbacks. (foobar) @ http://dev.openttdcoop.org/issues/3008 16:34:34 <FooBar> heh, now there's two bugreports :P 16:34:58 <Brot6> NewGRF Meta Language - Bug #3009 (New): CB_FAILED doesn't work in graphics block (Hirundo) @ http://dev.openttdcoop.org/issues/3009 16:35:30 <Brot6> NewGRF Meta Language - Bug #3009 (Rejected): CB_FAILED doesn't work in graphics block (Hirundo) @ http://dev.openttdcoop.org/issues/3009 16:35:30 <Brot6> NewGRF Meta Language - Bug #3009 (Rejected): CB_FAILED doesn't work in graphics block (Hirundo) @ http://dev.openttdcoop.org/issues/3009#change-7585 16:35:43 <Hirundo> Now there's one 16:36:01 <FooBar> :) 16:40:18 <Hirundo> I'll see if I can reproduce the 'superfluous switch' 16:41:00 <Brot6> NewGRF Meta Language - Bug #3007 (Closed): Assertion error with NARVS (oberhuemer) @ http://dev.openttdcoop.org/issues/3007 16:41:02 <Brot6> NewGRF Meta Language - Revision 1628:2baf6192412e: Fix #3007: not only check for too big but also... (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/2baf6192412e 16:41:02 <Brot6> NewGRF Meta Language - Bug #3007 (Closed): Assertion error with NARVS (yexo) @ http://dev.openttdcoop.org/issues/3007#change-7586 16:45:17 <Yexo> oberheumer is making a complete mess of the repo 16:45:21 <Yexo> none of the last 15 revisions compiles 16:48:43 <Rubidium> missing files? 16:48:57 <Hirundo> I can't reproduce anything superfluous, for me the default result of the CB36 switch is the graphics spritegroup specified in 'default' 16:49:21 <Hirundo> The switch containing CB_FAILED does have a double CB_FAILED, but that's to avoid returning the computed value as CB result 16:50:24 <Yexo> missing files, moving files but accidentally renaming some, simple syntax errors, you name it 16:55:23 <Hirundo> I'm off for tonight 16:55:39 <Hirundo> FooBar: Perhaps you could open a forum topic about the articulated part capacity thingie? 17:10:56 <Brot6> nml: update from r1627 to r1628 done - http://bundles.openttdcoop.org/nml/nightlies/r1628 17:11:38 <Brot6> North American Road Vehicle Set - Bug #3005 (Rejected): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/3005 17:11:38 <Brot6> North American Road Vehicle Set - Revision 45:748fcba13696: Added "cargo_age_period" for all vehi... (oberhuemer) @ http://dev.openttdcoop.org/projects/narvs/repository/revisions/748fcba13696 17:11:38 <Brot6> North American Road Vehicle Set - Bug #3005 (Rejected): DevZone compile failed (oberhuemer) @ http://dev.openttdcoop.org/issues/3005#change-7587 17:12:39 <Brot6> North American Road Vehicle Set - Feature #3006 (Closed): Set cargo_age_period (oberhuemer) @ http://dev.openttdcoop.org/issues/3006 17:12:39 <Brot6> North American Road Vehicle Set - Feature #3006 (Closed): Set cargo_age_period (oberhuemer) @ http://dev.openttdcoop.org/issues/3006#change-7588 17:12:57 <Brot6> narvs: compile of r45 still failed (#3005) - http://bundles.openttdcoop.org/narvs/nightlies/ERROR/r45 17:14:14 <Yexo> FooBar: I can't reproduce your problem with CB_FAILED 17:14:17 <Yexo> it works fine here 17:14:32 <Yexo> uhm, nvm 17:14:40 <Yexo> editing another file than I am compiling.... 17:17:24 <Brot6> North American Road Vehicle Set - Revision 46:8c98d10342f2: Dates were also in units (oberhuemer) @ http://dev.openttdcoop.org/projects/narvs/repository/revisions/8c98d10342f2 17:20:25 <Brot6> firs: update from r2495 to r2505 done - http://bundles.openttdcoop.org/firs/nightlies/r2505 17:22:13 <Brot6> Following repos didn't need a nightlies update: ogfx-trains (r251), narvs (ERROR r45), bros (r52), ogfx-industries (r122), opengfx (r727), ailib-tile (r16), foobarstramtracks (r23), transrapidtrackset (r28), 2cctrainset (r750), cets (r126), ailib-list (r32), opensfx (r97), ttdviewer (r34), worldairlinersset (r672), heqs (r639), openmsx (r97), basecosts (r25), nutracks (r208), nml (r1628), water-features (r51), 32bpp-extra (r40), manindu 17:22:13 <Brot6> (r7), newgrf_makefile (r305), ailib-direction (r17), ailib-common (r21), snowlinemod (r49), dutchtramset (r87), ai-admiralai (r75), swisstowns (r22), metrotrackset (r56), dutchroadfurniture (r12), spanishtowns (r10), frenchtowns (r6), grfpack (r279), ogfx-rv (r109), fish (r684), ogfx-landscape (r78), ttrs (r36), ogfx-trees (r51), swedishrails (r205), grfcodec (r833), ai-aroai (r39), german-townnames (r34), smts (r19), chips (r143), 17:22:16 <Brot6> belarusiantowns (r8), indonesiantowns (r41), ailib-string (r29), airportsplus (r122), comic-houses (r71) 17:23:23 <Brot6> narvs: update from r37 to r46 done (11 warnings) - http://bundles.openttdcoop.org/narvs/nightlies/r46 17:35:45 <Brot6> North American Road Vehicle Set - Feature #3010 (New): MCI J4500 (oberhuemer) @ http://dev.openttdcoop.org/issues/3010 17:47:44 <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: ogfx-trains, ogfx-industries (Diffsize: 747), foobarstramtracks, cets (436 warnings) (Diffsize: 462), manindu (Diffsize: 2), newgrf_makefile, dutchtramset, swisstowns, dutchroadfurniture, spanishtowns (Diffsize: 2), frenchtowns, ogfx-rv, ogfx-landscape (1 warnings), swedishrails, german-townnames (Diffsize: 1), belarusiantowns (Diffsize: 30), 17:47:45 <Brot6> indonesiantowns (1 warnings) (Diffsize: 1), airportsplus (2 warnings) 18:32:49 *** Zuu has joined #openttdcoop.devzone 18:41:55 *** JVassie has joined #openttdcoop.devzone 18:57:35 *** JVassie has quit IRC 19:03:19 <Brot6> clientpatches: compile of r22832 still failed (#2964) - http://bundles.openttdcoop.org/clientpatches/testing/ERROR/r22832 19:08:29 <Brot6> openttd-vehiclevars: update from r22817 to r22832 done - http://bundles.openttdcoop.org/openttd-vehiclevars/testing/r22832 19:09:58 <Brot6> serverpatches: compile of r22832 still failed (#2966) - http://bundles.openttdcoop.org/serverpatches/testing/ERROR/r22832 19:11:38 <Brot6> 32bpp-ez-patches: compile of r22832 still failed (#2446) - http://bundles.openttdcoop.org/32bpp-ez-patches/testing/ERROR/r22832 19:37:29 *** JVassie has joined #openttdcoop.devzone 19:44:11 *** Lakie has quit IRC 19:45:29 *** Lakie has joined #openttdcoop.devzone 20:02:03 *** JVassie has quit IRC 20:35:09 *** JVassie has joined #openttdcoop.devzone 20:50:32 *** JVassie has quit IRC 20:54:04 *** orudge has quit IRC 21:25:00 *** orudge has joined #openttdcoop.devzone 21:25:00 *** Lakie has quit IRC 21:46:05 <Brot6> North American Road Vehicle Set - Revision 47:2580993bd04a: added MCI J4500 (oberhuemer) @ http://dev.openttdcoop.org/projects/narvs/repository/revisions/2580993bd04a 21:49:19 <Brot6> North American Road Vehicle Set - Feature #3010 (Closed): MCI J4500 (oberhuemer) @ http://dev.openttdcoop.org/issues/3010 21:49:19 <Brot6> North American Road Vehicle Set - Feature #3010 (Closed): MCI J4500 (oberhuemer) @ http://dev.openttdcoop.org/issues/3010#change-7589 21:56:41 *** frosch123 has quit IRC 22:01:27 <Brot6> DictatorAI - Revision 159:b501c58ab154: .. (krinn) @ http://dev.openttdcoop.org/projects/ai-dictator/repository/revisions/b501c58ab154 22:07:39 <Brot6> North American Road Vehicle Set - Revision 48:7a7b1d601135: added purchase window string for tram... (oberhuemer) @ http://dev.openttdcoop.org/projects/narvs/repository/revisions/7a7b1d601135 22:14:13 *** Zuu has quit IRC 22:25:25 <Brot6> Central European Train Set - Feature #2924: Prussian steam engines - sprites (oberhuemer) @ http://dev.openttdcoop.org/issues/2924#change-7590 22:28:24 <Brot6> Central European Train Set - Feature #2924 (Assigned): Prussian steam engines - sprites (oberhuemer) @ http://dev.openttdcoop.org/issues/2924#change-7593 22:53:40 <Brot6> Central European Train Set - Feature #2924: Prussian steam engines - sprites (michi_cc) @ http://dev.openttdcoop.org/issues/2924#change-7594 22:59:06 <Brot6> Central European Train Set - Feature #2924: Prussian steam engines - sprites (michi_cc) @ http://dev.openttdcoop.org/issues/2924#change-7595 23:01:11 *** ODM has quit IRC 23:07:33 *** FooBar has quit IRC 23:12:40 <Brot6> North American Road Vehicle Set - Revision 49:9786a751e60d: German translation update (oberhuemer) @ http://dev.openttdcoop.org/projects/narvs/repository/revisions/9786a751e60d 23:12:40 <Brot6> North American Road Vehicle Set - Revision 50:eae790e925d3: fixed some offsets & lengths on artic... (oberhuemer) @ http://dev.openttdcoop.org/projects/narvs/repository/revisions/eae790e925d3 23:12:40 <Brot6> North American Road Vehicle Set - Revision 51:f4de46959712: fixed last offset errors (oberhuemer) @ http://dev.openttdcoop.org/projects/narvs/repository/revisions/f4de46959712 23:15:37 <Brot6> North American Road Vehicle Set - Revision 52:6b3556820765: Added tag 0.1.1 for changeset f4de469... (oberhuemer) @ http://dev.openttdcoop.org/projects/narvs/repository/revisions/6b3556820765 23:18:27 <Brot6> narvs: update from 0.1.0 to 0.1.1 done (11 warnings) - http://bundles.openttdcoop.org/narvs/releases/0.1.1 23:25:10 <Brot6> Central European Train Set - Feature #2924: Prussian steam engines - sprites (oberhuemer) @ http://dev.openttdcoop.org/issues/2924#change-7596