Log for #openttdcoop.devzone on 24th August 2011:
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) @
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) @
07:01:36  <Brot6> FIRS Industry Replacement Set - Feature #2413 (Closed): Improve Sugar Refinery graphics + layouts (andythenorth) @
07:08:42  <Brot6> FIRS Industry Replacement Set - Feature #2726 (Rejected): Control CC for Sugar Refinery (andythenorth) @
07:13:18  <Brot6> FIRS Industry Replacement Set - Revision 2499:f85fc95b2b56: Cleanup: remove un-needed pcx file (andythenorth) @
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) @
08:25:06  <Brot6> FIRS Industry Replacement Set - Feature #2741 (Closed): Finish reworking Recycling Plant graphics... (andythenorth) @
08:28:43  <Brot6> FIRS Industry Replacement Set - Code Review #2495 (Rejected): Colours of recycling plant (andythenorth) @
08:28:43  <Brot6> FIRS Industry Replacement Set - Revision 2501:ef77b6e0e158: Change: remove un-needed pcx file (andythenorth) @
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) @
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) @
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) @
09:15:58  <Brot6> FIRS Industry Replacement Set - Revision 2503:3ee6e4bc38f1: Change: add building snow to Glass Works (andythenorth) @
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> <--- 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: <-- 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 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) @
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) @
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) @
12:11:04  <Brot6> FIRS Industry Replacement Set - Revision 2505:0d9886f3c26d: Change: add building snow to brick Gr... (andythenorth) @
12:11:04  <Brot6> FIRS Industry Replacement Set - Feature #2755: Grain Mill snow sprites need finishing (andythenorth) @
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) @
12:11:42  <Terkhen> so... any code task?
12:11:44  <andythenorth> #2986 ?
12:11:44  <Brot6> andythenorth: #2986 is "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 "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. 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
14:23:45  <orudge> ah, well, 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) @
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) @
15:47:54  <Brot6> narvs: compile of r41 still failed (#2983) -
15:52:19  <Brot6> North American Road Vehicle Set - Revision 42:6cc99310d654: re-added missing files (oberhuemer) @
15:54:15  <Brot6> North American Road Vehicle Set - Bug #2983 (Closed): DevZone compile failed (oberhuemer) @
15:54:15  <Brot6> North American Road Vehicle Set - Bug #3004 (New): DevZone compile failed (compiler) @
16:03:49  <Brot6> North American Road Vehicle Set - Revision 43:ac671513d886: Vehicle properties should be entered ... (oberhuemer) @
16:04:51  <Brot6> North American Road Vehicle Set - Bug #3004 (Closed): DevZone compile failed (compiler) @
16:04:51  <Brot6> North American Road Vehicle Set - Bug #3004 (Closed): DevZone compile failed (oberhuemer) @
16:06:11  <Brot6> North American Road Vehicle Set - Bug #3005 (New): DevZone compile failed (compiler) @
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) @
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) @
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) @
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>
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:
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) @
16:29:06  <Brot6> NewGRF Meta Language - Bug #3007: Assertion error with NARVS (oberhuemer) @
16:30:25  <Brot6> FIRS Industry Replacement Set - Bug #3003: Change min compatible version prior to release / branch (planetmaker) @
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) -
16:33:54  <Brot6> NewGRF Meta Language - Bug #3008 (New): cannot use return CB_FAILED; in graphics block callbacks. (foobar) @
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) @
16:35:30  <Brot6> NewGRF Meta Language - Bug #3009 (Rejected): CB_FAILED doesn't work in graphics block (Hirundo) @
16:35:30  <Brot6> NewGRF Meta Language - Bug #3009 (Rejected): CB_FAILED doesn't work in graphics block (Hirundo) @
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) @
16:41:02  <Brot6> NewGRF Meta Language - Revision 1628:2baf6192412e: Fix #3007: not only check for too big but also... (yexo) @
16:41:02  <Brot6> NewGRF Meta Language - Bug #3007 (Closed): Assertion error with NARVS (yexo) @
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 -
17:11:38  <Brot6> North American Road Vehicle Set - Bug #3005 (Rejected): DevZone compile failed (compiler) @
17:11:38  <Brot6> North American Road Vehicle Set - Revision 45:748fcba13696: Added "cargo_age_period" for all vehi... (oberhuemer) @
17:11:38  <Brot6> North American Road Vehicle Set - Bug #3005 (Rejected): DevZone compile failed (oberhuemer) @
17:12:39  <Brot6> North American Road Vehicle Set - Feature #3006 (Closed): Set cargo_age_period (oberhuemer) @
17:12:39  <Brot6> North American Road Vehicle Set - Feature #3006 (Closed): Set cargo_age_period (oberhuemer) @
17:12:57  <Brot6> narvs: compile of r45 still failed (#3005) -
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) @
17:20:25  <Brot6> firs: update from r2495 to r2505 done -
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) -
17:35:45  <Brot6> North American Road Vehicle Set - Feature #3010 (New): MCI J4500 (oberhuemer) @
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) -
19:08:29  <Brot6> openttd-vehiclevars: update from r22817 to r22832 done -
19:09:58  <Brot6> serverpatches: compile of r22832 still failed (#2966) -
19:11:38  <Brot6> 32bpp-ez-patches: compile of r22832 still failed (#2446) -
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) @
21:49:19  <Brot6> North American Road Vehicle Set - Feature #3010 (Closed): MCI J4500 (oberhuemer) @
21:49:19  <Brot6> North American Road Vehicle Set - Feature #3010 (Closed): MCI J4500 (oberhuemer) @
21:56:41  *** frosch123 has quit IRC
22:01:27  <Brot6> DictatorAI - Revision 159:b501c58ab154: .. (krinn) @
22:07:39  <Brot6> North American Road Vehicle Set - Revision 48:7a7b1d601135: added purchase window string for tram... (oberhuemer) @
22:14:13  *** Zuu has quit IRC
22:25:25  <Brot6> Central European Train Set - Feature #2924: Prussian steam engines - sprites (oberhuemer) @
22:28:24  <Brot6> Central European Train Set - Feature #2924 (Assigned): Prussian steam engines - sprites (oberhuemer) @
22:53:40  <Brot6> Central European Train Set - Feature #2924: Prussian steam engines - sprites (michi_cc) @
22:59:06  <Brot6> Central European Train Set - Feature #2924: Prussian steam engines - sprites (michi_cc) @
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) @
23:12:40  <Brot6> North American Road Vehicle Set - Revision 50:eae790e925d3: fixed some offsets & lengths on artic... (oberhuemer) @
23:12:40  <Brot6> North American Road Vehicle Set - Revision 51:f4de46959712: fixed last offset errors (oberhuemer) @
23:15:37  <Brot6> North American Road Vehicle Set - Revision 52:6b3556820765: Added tag 0.1.1 for changeset f4de469... (oberhuemer) @
23:18:27  <Brot6> narvs: update from 0.1.0 to 0.1.1 done (11 warnings) -
23:25:10  <Brot6> Central European Train Set - Feature #2924: Prussian steam engines - sprites (oberhuemer) @

Powered by YARRSTE version: svn-trunk