Times are UTC Toggle Colours
07:44:47 <Brot6> OpenGFX+ Road Vehicles - Revision 128:f62170e0310f: Fix: Correct the NewGRF description. (Terkhen) @ http://dev.openttdcoop.org/projects/ogfx-rv/repository/revisions/f62170e0310f 07:45:58 <planetmaker> Terkhen: iirc it's spellt "extents" instead of "extends" 07:46:06 <planetmaker> but I might be wrong, too 07:46:58 <planetmaker> hm... nvm me. One is verb, the other noun 07:47:01 <planetmaker> you're right :-) 07:49:28 <Terkhen> I copied it from the readme / website description 07:49:34 <Terkhen> I just forgot to correct it there too :P 07:49:46 <Terkhen> at least, now if it is wrong, it is equally wrong everywhere :) 07:50:08 <planetmaker> no, it's right :-) 07:50:55 <Terkhen> ok :) 08:05:23 *** ODM has joined #openttdcoop.devzone 08:28:15 <Brot6> OpenGFX+ Road Vehicles - Revision 129:9b8a82ccdc12: Add: Spanish translation. (Terkhen) @ http://dev.openttdcoop.org/projects/ogfx-rv/repository/revisions/9b8a82ccdc12 08:35:12 <Brot6> FIRS Industry Replacement Set - Revision 2598:983eeccb3116: Add: Hungarian translation (Brumi) (planetmaker) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/983eeccb3116 09:00:26 <Brot6> FIRS Industry Replacement Set - Revision 2599:b4043d7da450: Change: Update readme, include transl... (planetmaker) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/b4043d7da450 09:01:36 <planetmaker> ^ that was really needed ;-) 09:11:04 <Brot6> FIRS Industry Replacement Set - Feature #2736 (Closed): Hungarian Translation (planetmaker) @ http://dev.openttdcoop.org/issues/2736#change-7880 09:14:08 <Ammler> hmm, shouldn't you rather credit the author then the origin set? 09:14:33 <Ammler> like who draw the Aluminium plant fro opengfx 09:14:50 <planetmaker> yes, we should, I think 09:14:52 <Ammler> I mean, isn't that the reason, we maintain the credits table there 09:15:04 <planetmaker> In this case I simply copied from the existing credits file 09:15:44 <planetmaker> indeed I could and should have looked it up for the OpenGFX case 09:15:50 <planetmaker> lazyness was stronger, though 09:17:34 <Ammler> ah well, then we blame andy :-) 09:19:55 <planetmaker> yeah, easy ;-) 11:17:33 <planetmaker> hm... is there a nice way to get random bits in the form of a variable I can use in an expression, Hirundo, Yexo? 11:18:07 <planetmaker> like STORE_PERM(randomvar(0,3)*2, 0) 11:18:24 <planetmaker> or like STORE_PERM(4 + randomvar(0,3), 0) 11:18:25 <Yexo> var 5F 11:18:34 <Yexo> not sure if we have a name for that one 11:19:02 <planetmaker> hm, what was the exact syntax, can you remind me (we should document that ;-) ) 11:19:43 <Yexo> the variable random_bits works for vehicles 11:20:09 <Yexo> industries and objects have nearby_tile_random_bits(x, y) 11:20:57 <Yexo> for which feature do you need it? 11:22:25 <planetmaker> industries itself 11:22:53 <planetmaker> I saw the nearby_tile_random_bits, but that seems inappropriate to initialize temporary storage for the industry 11:23:00 <Yexo> it is 11:23:14 <planetmaker> s/temporary/permanent/ 11:23:49 <planetmaker> other question at the same time: initialization of perm. storage: where is it best done? 11:23:54 <planetmaker> In the industry's location check? 11:24:30 <Yexo> is it already available at that time? 11:24:37 <planetmaker> Not sure :-) 11:25:39 <Brot6> NewGRF Meta Language - Revision 1666:9cfa7bc85dcd: Add: var 'random_bits' (0x5F) for industries (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/9cfa7bc85dcd 11:26:44 <planetmaker> eh, start: 8 ? 11:26:47 <Yexo> yes 11:26:53 <planetmaker> what are the first 8 bits? 11:26:58 <Yexo> lowest byte of var 5F is the triggers 11:27:01 <Brot6> NewGRF Meta Language - Bug #3076 (New): Make var "random_bits" available for all features (yexo) @ http://dev.openttdcoop.org/issues/3076 11:27:01 <planetmaker> ah 11:28:03 <planetmaker> thx. Still, the var[0xAA, bit, count, param] (is that right?) should be documented somewhere for experimental code 11:28:18 <planetmaker> i.e. new features NML doesn't yet know about 11:30:06 <Yexo> Hirundo: wanted to remove that syntax completely 11:30:20 <planetmaker> I know. I still don't like that idea 11:30:26 <Yexo> it's almost right, where you write "count" you should have "mask" 11:30:30 <planetmaker> it makes it impossible to use NML to test new OpenTTD stuff 11:30:54 <Yexo> I don't think we ever will (if only because it makes writing a grf->nml decompiler that much harder) 11:31:27 <planetmaker> he :-) 11:31:50 <planetmaker> hm, but where to document it? 11:31:57 <planetmaker> in the additional references? 11:35:02 <planetmaker> I'll create a page called 'deprecated syntax'... hm... could go into a renamed 'old style callbacks'? 11:35:48 <planetmaker> no, that's too lengthy 12:08:49 *** ODM has quit IRC 12:32:46 <Hirundo> Documentation for var[..] should very clearly state that it's meant for experimental use onl 12:33:31 <planetmaker> http://newgrf-specs.tt-wiki.net/wiki/NML:Deprecated_syntax 12:34:17 <planetmaker> Might not be ideal... but I keep forgetting the syntax. Feel free to improve it 12:37:07 <Hirundo> *edits* 12:44:04 <planetmaker> :-) 12:44:16 <Hirundo> I made some fixes/additions, mind that it is var[] not param[] 12:44:27 <Hirundo> getting that wrong can be painful 12:44:29 <planetmaker> hm, yes :-) 12:44:32 <Hirundo> :-) 13:21:05 <planetmaker> hm... can I work with negative number in temporary and permanent storage? 13:22:35 <Hirundo> sure, it's all just bits and bytes 13:23:04 <planetmaker> well, not that -1 gets interpreted as 255 or 65535 or so 13:23:34 <Hirundo> -1 and 0xFFFFFFFF are actually the same when it comes to addition/subtraction/multiplication 13:24:08 <planetmaker> hm, are they? 13:24:14 <planetmaker> -1 * -1 = 1 13:24:33 <planetmaker> 0xFFFFFFFF * 0xFFFFFFFF = overflow ;-) 13:25:06 <planetmaker> it depends whether it's interpreted as signed or not really 13:25:19 <planetmaker> as -1 with signed would be 0x80000001 13:25:33 <Hirundo> no 13:25:46 <Hirundo> -1 signed is 0xFFFFFFFF 13:26:31 <Hirundo> 0x7f = 127, 0x80 = -128 13:26:39 <Hirundo> (assuming 8 bits, which saves typing) 13:27:40 <planetmaker> http://en.wikipedia.org/wiki/Signed_number_representations <-- hm, always? 13:27:41 <Webster> Title: Signed number representations - Wikipedia, the free encyclopedia (at en.wikipedia.org) 13:30:13 <Hirundo> It should always work as long as overflow is handled as expected (FF + 1 = 0) 13:30:36 <Hirundo> All numbers outputted by NML are unsigned anyways, it's interpretation that makes them signed 13:31:49 <planetmaker> http://paste.openttdcoop.org/show/576/ <-- so that works nicely? 13:32:16 <planetmaker> and the grf won't clamp 5 -9 to 0? 13:33:37 <Hirundo> That should work 13:34:27 <Yexo> be very careful with that, since -x..0 doesn't work 13:34:35 <Yexo> and neither does -x..+y 13:34:55 <Hirundo> Feature request: Fix that in NML 13:35:06 <Hirundo> *creates* 13:35:13 <Yexo> as long as the ranges are constant, we can 13:35:19 <planetmaker> the application I have in mind is: compute a proxy for the production decrease (<0) or production increase (>0) chance - or 0 for no change 13:35:40 <Yexo> so we can either fix this or implement #2979 13:35:42 <Brot6> Yexo: #2979 is http://dev.openttdcoop.org/issues/show/2979 "NewGRF Meta Language - Feature Request #2979: usage of variables in ranges for switches - #openttdcoop Development Zone" 13:35:56 <Yexo> we cannot reliable do both 13:36:44 <planetmaker> rather have variables 13:36:48 <Yexo> actually nevermind that 13:37:13 <Yexo> if we implement that task as suggested by rewriting than it can work, since the actual ranges are still only constants 13:37:59 <Hirundo> Action 6/D may be used though 13:38:13 <Yexo> not for ranges, since we can't detect negative numbers 13:38:32 <Yexo> nml can't rewrite "param[3] .. 0" for param[3]=-2 automatically 13:39:12 <Hirundo> no(t until proper int/uint distinction is made) 13:39:13 <Yexo> so even if it could be done by Action 6/D we have to use another varaction2 to see if the value is inside the range 13:40:21 <Hirundo> considering parameters to be unsigned should be safe for now 13:41:26 <Yexo> we could make named-parameter handling so much easier if we adopted a more functional-language approach 13:42:10 <Yexo> only allow them to be assigned once and never change, order of definition doesn't have to matter in that case (as long as loops are avoided) 13:42:52 <Yexo> it'd also get rid of #2785 13:42:53 <Brot6> Yexo: #2785 is http://dev.openttdcoop.org/issues/show/2785 "NewGRF Meta Language - Bug #2785: problem with spritelayout parameters - #openttdcoop Development Zone" 13:43:21 <Yexo> and it'd be a lot easier for NML to optimize much more aggressively 13:47:04 <Hirundo> Would if (...) a = foo + bar } else { a = 0 } still work then? 13:47:34 <Yexo> no, you'd have to write that as something like "a = ... ? foo + bar : 0;" 13:58:15 <Terkhen> planetmaker: whenever I commit, all png files are recreated 13:58:19 <Terkhen> is there any way to avoid this? 13:58:38 <planetmaker> ogfx+rv? 13:59:50 <Terkhen> yes 14:00:09 <planetmaker> does it help, when I say I'm currently (not right now, but generally) struggling to make that work (better)? 14:00:13 <Terkhen> I committed a translation, and now that I have added another one it is creating all png files 14:00:17 <Terkhen> it does :P 14:00:53 <planetmaker> I need it for the river graphics as that's literally dozens of files and layers. And... it doesn't work for me right now 14:00:56 <planetmaker> which sucks 14:02:08 <planetmaker> but it frustrated me a bit last weekend, so I put it for a rest for at at least a few days ;-) 14:02:57 <Terkhen> there is no hurry :) 14:03:19 <Brot6> OpenGFX+ Road Vehicles - Revision 130:5942eb5824b2: Update: Russian translation. (Terkhen) @ http://dev.openttdcoop.org/projects/ogfx-rv/repository/revisions/5942eb5824b2 14:03:19 <Brot6> OpenGFX+ Road Vehicles - Revision 131:6e5a075906df: Add: Hungarian translation. (DXTR) (Terkhen) @ http://dev.openttdcoop.org/projects/ogfx-rv/repository/revisions/6e5a075906df 14:04:54 <planetmaker> the current psd/xcf -> png implementation is a hack all the way through the makefile... 14:05:17 <planetmaker> and yes, it takes ages... 14:07:05 <planetmaker> hm, I should create a German translation, it seems 14:07:43 <Terkhen> that would be good, yes :) 14:07:49 <Terkhen> it is short, and you can copy many strings from ogfx-trains :P 14:11:05 <Brot6> Vactrain Set - Feature Request #3077 (New): Update readme (Terkhen) @ http://dev.openttdcoop.org/issues/3077 14:13:15 <planetmaker> He, thanks for the tipp :-) 14:15:41 <Terkhen> :) 14:17:43 <Ammler> planetmaker: maybe make a target help for makefile and then remove the target explainations from newgrf readme 14:19:19 <planetmaker> Ammler: that exists already 14:19:24 <planetmaker> hm.. no, it's called test 14:19:29 <planetmaker> yes, an idea :-) 14:23:44 <planetmaker> hm... names of vehicles cannot be composed of several strings... 14:24:02 <Terkhen> what do you mean? 14:24:19 <Ammler> just think the main part of the newgrf readme is about building :-) 14:25:03 <Ammler> you could also make an additional file compile.txt or so 14:25:13 <Ammler> or build.txt 14:25:31 <Ammler> makefile.txt 14:25:54 <Yexo> nobody reads that file anyway :p 14:26:04 <Ammler> the readme? 14:26:08 <Yexo> yes 14:26:09 <planetmaker> Terkhen: I mean like "Dash {STRING}" where {STRING} would be replaced by {STR_FLATBED} 14:26:15 <Terkhen> oh 14:26:20 <Terkhen> that would be nice :P 14:26:28 <planetmaker> But I think it doesn't work 14:26:38 <Ammler> Yexo: might change with ingame readme viewer :-) 14:26:55 <planetmaker> Ammler: as such I'd like to keep that info in the readme (too) 14:27:05 <planetmaker> doesn't mean there can't be a target 'make help' 14:27:13 <Yexo> Ammler: has anyone taken over from LordAro? 14:27:17 <Ammler> oh well, that is the whole point 14:27:18 <planetmaker> littering that over many files IMHO doesn't help 14:27:43 <Ammler> the makefile explaination in the readme is very unneeded for common user 14:27:43 <Yexo> <planetmaker> Terkhen: I mean like "Dash {STRING}" where {STRING} would be replaced by {STR_FLATBED} <- I think that is already supported 14:27:45 <Yexo> let me test 14:28:18 <planetmaker> hm, it is? 14:28:26 <planetmaker> it's an action0 property 14:29:03 <Yexo> name: string(STR_TEST1, string(STR_TEST2)); 14:29:08 <Yexo> STR_TEST1 :My little {STRING} 14:29:10 <Yexo> STR_TEST2 :test22 14:29:32 <planetmaker> hm, really? :-) 14:29:40 <Yexo> output is: 5 * 24 04 01 7F 01 FF \wx0058 "My little test22" 00 14:29:50 <planetmaker> again learnt something new :-) 14:29:50 <Yexo> I implemented that a few weeks ago 14:30:03 <planetmaker> hm... like the FIRS error strings, I guess 14:30:08 <Yexo> yes 14:30:21 <planetmaker> I guess Terkhen got a change to make :-P 14:30:25 <Yexo> name: string(STR_TEST1, "hello"); <- that would work as well 14:30:47 <Terkhen> nice :P 14:30:57 <Terkhen> but not now, I'm already requesting translations 14:31:05 <planetmaker> Does it matter? 14:31:06 <Terkhen> I don't want to make them write it all a third time :P 14:31:32 <planetmaker> It doesn't invalidate the old ones 14:31:48 <Yexo> it does actually 14:31:57 <planetmaker> parameter? 14:32:10 <Yexo> all translations needs to have the same number of parameters 14:32:24 <planetmaker> well, void strings could be added 14:32:29 <Yexo> if in english you have "some str {STRING}" you must also have that {STRING} in all translations 14:33:20 <Terkhen> yes, that's what I thought 14:33:44 <Terkhen> the amount of duplication removed is not enough to make me ask them to translate again :P 14:34:59 <planetmaker> :-) 14:35:07 <Brot6> OpenGFX+ Road Vehicles - Revision 132:27de3196310d: Add: German translation (planetmaker) @ http://dev.openttdcoop.org/projects/ogfx-rv/repository/revisions/27de3196310d 14:35:13 <Yexo> Terkhen: it depends on how you handle strings that don't need to be translated 14:35:38 <Terkhen> hmm... all of them except maybe the title need translating 14:35:44 <Yexo> it seems that all current translations copy the exact manufacturer 14:35:52 <Yexo> STR_PARAM_COST_BY32 and friends don't need to 14:36:08 <Yexo> anyway, if you copy the manufacturer from english you'd onlyhave to translate the first part once instead of 3 times 14:40:22 <planetmaker> yup 14:40:50 <Yexo> but even with the above I agree on your decision not to change it now :) 14:40:58 <planetmaker> yup :-) 14:41:14 <planetmaker> it's not like it's an enormous amount of c&p involved :-) 14:46:25 <Terkhen> :) 14:49:25 <planetmaker> Yexo: in a switch case something like 14:49:48 <planetmaker> LOAD_PERM(0)/3 ... LOAD_PERM(0): blah 14:49:52 <planetmaker> doesn't yet work, right? 14:50:08 <Yexo> as range? no 14:50:19 <planetmaker> as range, yes. thought so. Thanks 14:50:33 <Yexo> that's #2979 14:50:33 <Brot6> Yexo: #2979 is http://dev.openttdcoop.org/issues/show/2979 "NewGRF Meta Language - Feature Request #2979: usage of variables in ranges for switches - #openttdcoop Development Zone" 14:50:45 <planetmaker> :-) 15:32:45 <Brot6> Central European Train Set - Feature #3045: Wagons - sprites (oberhuemer) @ http://dev.openttdcoop.org/issues/3045#change-7881 15:36:54 *** ODM has joined #openttdcoop.devzone 15:54:09 <planetmaker> Question wrt NewGRF strings (NML): "{BLACK}Requires {STRING} per month.{}Current storage: {STRING}" with the included {STRING} "{SIGNED_WORD} crate{P 0 "" s} of engineering supplies" - does that work, if so how? 16:05:08 <Yexo> in {P 0 the "0" indicates it refers to the first argument, which is {STRING}, as such it doesn't make sense 16:05:21 <Yexo> in this case it should be {P 3 "" s} instead 16:06:05 <Yexo> and that only if the first three {STRING}'s don't take arguments themselves 16:06:44 <planetmaker> it should both be about the same 16:07:05 <planetmaker> ok, so better include the arguments all in the same string 16:07:13 <Yexo> yes 16:07:14 <planetmaker> and not nest them 16:09:32 <planetmaker> hm... 16:09:51 <planetmaker> but maybe I'll nevertheless nest it... as it could also be farm supplies 16:10:11 <planetmaker> hm... no, then the param doesn't work. drat 16:12:03 <Yexo> the param does work 16:12:11 <Yexo> but you'll have to account even for arguments in sub-params 16:13:12 <planetmaker> yeah. And that'll fail horribly if I include the same string twice. But with the intention of different amount of the cargo 16:13:31 <Yexo> huh? 16:14:48 <planetmaker> Well. As in the example above: I want a string like "Currently requires 12t farm supplies per month. Delivered this month: 6t farm supplies 16:15:02 <Yexo> would would that fail horribly? 16:15:05 <planetmaker> where the amount is a different variable. And the supply type is a variable, too 16:15:19 <planetmaker> as including the same string would always reference the 1st number / argument? 16:15:32 <Yexo> perhaps it currently does ;( 16:15:44 <planetmaker> that's how I understood you 16:16:07 <Yexo> you misunderstood, but I'm not sure that example can currently be done 16:16:40 <planetmaker> hm, so I should try? :-) 16:18:33 <Yexo> please do and report back if you can get it to work :) 16:19:56 <planetmaker> will do :-) 16:20:15 <planetmaker> I'm having fun with firs primary supply usage :-) 17:12:42 <Brot6> OpenGFX+ Road Vehicles - Feature #3078 (New): Dutch translation (foobar) @ http://dev.openttdcoop.org/issues/3078 17:18:14 <Yexo> Terkhen: why are you checking the "dynamic_engines" variable? 17:18:40 <Yexo> whatever the value of that setting, you can have as many IDs in your grf as you like 17:18:53 <Yexo> the only influence that setting is on overwriting vehicles from other grfs 17:22:53 <Brot6> FIRS Industry Replacement Set - Feature #2296: Supplying Mechanism (planetmaker) @ http://dev.openttdcoop.org/issues/2296#change-7882 17:24:05 <planetmaker> Yexo: the idea is to tell the user "please enable this setting" 17:24:33 <planetmaker> i.e. the anti-thesis of Pikka's parameter ;-) 17:25:09 <planetmaker> it's not a fatal error. But an error so that it opens an actual window (warnings and notices don't do that) 17:26:02 <Terkhen> Yexo: it is pm's code :P 17:26:16 <planetmaker> :-P 17:26:20 <planetmaker> I suspected so 17:26:50 <planetmaker> then my explanation should be right 17:27:00 <Terkhen> yes, that's how I understood that too 17:31:29 <planetmaker> I'm quite convinced that it's a setting which should always be on 17:31:37 <planetmaker> except maybe in some ancient savegame files 17:31:52 <Yexo> that makes sense :) 17:33:23 <Yexo> in ancient savegame files you shouldn't have ogfx+rvs 17:35:31 <planetmaker> yes, certainly not. It was rather an argument for "let's kill the GUI part of that setting" ;-) 17:54:52 <planetmaker> Yexo: you were interested in the result: http://dev.openttdcoop.org/attachments/1892/industry_view.png with the patches as found in http://devs.openttd.org/~planetmaker/patches/firs/ (namely 100_...) 17:55:11 <planetmaker> not quite what I expected... 17:56:01 *** frosch123 has joined #openttdcoop.devzone 17:56:17 <planetmaker> quak 17:56:23 <frosch123> moin 17:59:08 *** andythenorth has joined #openttdcoop.devzone 18:00:51 <planetmaker> hi ho andythenorth 18:01:02 <andythenorth> ho hi 18:01:28 <planetmaker> http://dev.openttdcoop.org/attachments/1892/industry_view.png <-- looking at a typical industry... I think it will look better when we really use the actual stockpile 18:01:41 <planetmaker> it avoids duplication and confusing information 18:02:43 <andythenorth> wrt supplies? 18:03:12 <planetmaker> jo 18:04:02 <planetmaker> would there be any detriment if we use the in-built stockpile for our purpose? 18:04:43 <andythenorth> can't remember 18:04:48 <andythenorth> iirc it doesn't work as required 18:04:59 <andythenorth> and the display will still be sub-optimal at best 18:05:07 <planetmaker> How so? 18:05:19 <planetmaker> It shows the currently present supplies 18:05:27 <planetmaker> which we want among other info 18:05:27 * andythenorth wonders how we're doing supplies 18:05:32 <andythenorth> ticket... 18:05:46 <planetmaker> http://dev.openttdcoop.org/issues/2296 18:10:11 <andythenorth> biab 18:10:14 <andythenorth> bathtime 18:12:55 <andythenorth> planetmaker: we could use built-in stockpile, it requires that we can add/remove from stockpile at will (we can) 18:12:57 <andythenorth> however 18:13:07 <andythenorth> I don't like that string / display 18:13:16 <andythenorth> I would rather patch ottd to toggle it off 18:13:21 <planetmaker> But we have that anyway it seems 18:13:24 <andythenorth> or provide industry with full control 18:14:19 <andythenorth> the relevant part of supplies spec is : 18:14:20 <andythenorth> "So if industry is working at '3x normal rate to increase production', and it's baseline requirement is 30t then delivering >90t is pointless (although possible - they are just consumed, but not added to supply_store)" 18:14:29 <andythenorth> but that is possible with stockpile 18:15:35 <andythenorth> I think the reason I wanted to avoid built-in stockpile string is that it's not needed to display current store in cargo units 18:15:45 <andythenorth> and it's going to cause bug reports if we do 18:16:36 <planetmaker> hu? why? 18:17:33 <planetmaker> cargo waiting to be processed: x crates of eng supplies (...) 18:17:55 <planetmaker> Required per month: N crates of eng supplies{}... 18:18:00 <planetmaker> doesn't sound confising to me 18:19:03 <andythenorth> because we're going to put a cap on the stockpile 18:19:11 <andythenorth> otherwise it's unbounded 18:19:22 <andythenorth> so we'll get bug reports about 'lost' cargo delivery 18:19:41 <andythenorth> if we don't cap it, this new-otherwise-perfect scheme is again dumb-assed 18:20:12 <planetmaker> this has nothing to do with capping it 18:20:31 <andythenorth> if you use the stockpile string, players will report cargo being lost 18:20:36 <andythenorth> unless I misunderstand 18:20:44 <andythenorth> which is (a) possible 18:20:48 <andythenorth> (b) today, quite likely 18:20:52 <planetmaker> :-) 18:21:07 <planetmaker> that's a point. But it can be indicated in the extra text 18:21:46 <andythenorth> but then you swap one extra bit of text for another 18:22:09 <planetmaker> but I could save a parameter 18:22:12 <andythenorth> I haven't spent much time thinking about this recently, if you've been trying to patch you are probably ahead of me in thinking 18:22:17 <planetmaker> or put other useful info there :-) 18:22:42 <planetmaker> I started... http://devs.openttd.org/~planetmaker/patches/firs/ 18:22:59 <andythenorth> I would do the patch with separate text as per screenshot 18:23:03 <planetmaker> not tested and string not working 18:23:09 <andythenorth> then we can sort out the stockpile later 18:23:21 <andythenorth> I want to remove that stockpile string, I find it stupid 18:23:27 <planetmaker> uhm... I don't think that's a good approach 18:23:38 <andythenorth> it's incorrect behaviour that enabling production cb also enables stockpile 18:23:43 <andythenorth> they are not coupled 18:23:54 <andythenorth> ^^ (stockpile string) 18:24:59 <andythenorth> there should be a flag or cb that lets industry author replace all industry window text with custom 18:25:09 <andythenorth> maybe setting extra bits on current cb? 18:25:18 <andythenorth> or put a value in register 18:25:38 <andythenorth> frosch123 might have ideas 18:27:09 <Brot6> OpenGFX+ Road Vehicles - Feature #3078 (Closed): Dutch translation (foobar) @ http://dev.openttdcoop.org/issues/3078 18:27:09 <Brot6> OpenGFX+ Road Vehicles - Revision 133:495443cc04d2: Add #3078: Dutch translation. (Foobar) (Terkhen) @ http://dev.openttdcoop.org/projects/ogfx-rv/repository/revisions/495443cc04d2 18:27:09 <Brot6> OpenGFX+ Road Vehicles - Feature #3078 (Closed): Dutch translation (Terkhen) @ http://dev.openttdcoop.org/issues/3078#change-7883 18:27:19 <Terkhen> planetmaker: thanks for the translation :) 18:27:26 <planetmaker> no problem. 18:27:41 <planetmaker> after all I'm still one of the authors according to the NewGRF description :-P 18:27:53 <Terkhen> :P 18:27:57 <planetmaker> sounds a bit like an exageration tbh 18:28:05 <Terkhen> same for me in ogfx-trains 18:28:17 <Terkhen> so we are even :P 18:28:37 <planetmaker> he, yeah :-9 18:28:39 <planetmaker> :-) 18:30:38 <planetmaker> but ok, andythenorth, I'll do w/o the 'official' stockpile - though we're actually using a stockpile 18:30:48 <andythenorth> best route I think :) 18:30:49 <andythenorth> thanks 18:30:59 <andythenorth> best that we keep our own stockpile 18:31:24 <andythenorth> I would even call it something else to avoid name collisions :P 18:31:27 <Terkhen> patch openttd with a flag to disable the stockpiling string :) 18:31:30 <planetmaker> hm... we could really just process the cargo we need... and not even store it in the register(s) 18:31:48 <andythenorth> supply_cache 18:32:04 <andythenorth> Terkhen: flag is a bad route I think, flags are usually wrong :) 18:32:10 <andythenorth> extending current cb would be better 18:32:38 <andythenorth> cb 3A 18:32:38 <andythenorth> http://newgrf-specs.tt-wiki.net/wiki/Callbacks#Show_additional_text_in_industry_window_.283A.29 18:33:09 <andythenorth> wonder if we can set a bit somewhere 18:33:15 <andythenorth> registers 100-105h are used 18:33:23 <andythenorth> that's one place where bits could have been set for this 18:33:47 <andythenorth> can we set an extra bit on the return value of the cb? 18:41:11 <planetmaker> andythenorth: we don't actually need a supply_cache... 18:41:18 <planetmaker> if we just keep waiting_cargo_1 as it 18:41:24 <planetmaker> no reason not to do so 18:46:25 <planetmaker> hm. 18:49:30 <andythenorth> so we just manipulate the value of that? 18:50:51 <planetmaker> I just wonder :-) 18:50:55 <planetmaker> maybe we can't 18:51:07 <planetmaker> we can't call the produce thingy monthly 18:51:13 <planetmaker> but only every 256 ticks or so 18:51:20 <planetmaker> which ... would also work. But... meh 18:51:42 <planetmaker> @calc 256 / 74 18:51:42 <Webster> planetmaker: 3.45945945946 18:51:51 <planetmaker> @calc 30 / (256 / 74) 18:51:51 <Webster> planetmaker: 8.671875 18:52:29 <planetmaker> it would ensure a steady consumption ;-) 18:56:39 <andythenorth> we need to use the regular consumption cb, or on cargo delivered 18:56:43 <andythenorth> on cargo delivered should be fine 18:56:54 <andythenorth> the prod. boost cb is then monthly 18:58:00 <planetmaker> yeah, that it is. But producing monthly would be nice in this case ;-) 19:05:49 <Brot6> clientpatches: compile of r22931 still failed (#2964) - http://bundles.openttdcoop.org/clientpatches/testing/ERROR/r22931 19:08:09 <andythenorth> planetmaker: it will come to the same in the maths 19:08:14 <andythenorth> although the user won't see it that way 19:08:15 <andythenorth> hmm 19:08:17 <andythenorth> they could 19:08:20 <andythenorth> nvm 19:08:40 <planetmaker> the continuously eating industry 19:08:55 <planetmaker> the 256ticks CB has the disadvantage that it scales badly wrt small amounts 19:09:18 <andythenorth> it should 'just' work on delivery, unless I miss something 19:09:42 <andythenorth> calculate when delivered, calculate on prod. change cb 19:10:44 <planetmaker> hm. yes 19:12:44 * planetmaker got an idea 19:12:47 <andythenorth> :) 19:13:04 <andythenorth> planetmaker: it requires some familiarity with those cbs to make best use of them 19:13:12 <andythenorth> you have to think in different cadences 19:13:15 <planetmaker> yes it does :-) 19:13:20 <andythenorth> delivered-256-monthly 19:13:30 <andythenorth> but it does work quite well 19:13:38 <andythenorth> they're not the worst thing in nfo spec :P 19:14:18 <planetmaker> no, they aren't 19:15:30 <Brot6> openttd-vehiclevars: update from r22930 to r22931 done - http://bundles.openttdcoop.org/openttd-vehiclevars/testing/r22931 19:17:49 <Brot6> serverpatches: compile of r22931 still failed (#2966) - http://bundles.openttdcoop.org/serverpatches/testing/ERROR/r22931 19:19:45 <Brot6> 32bpp-ez-patches: compile of r22931 still failed (#2446) - http://bundles.openttdcoop.org/32bpp-ez-patches/testing/ERROR/r22931 19:45:56 <planetmaker> http://devs.openttd.org/~planetmaker/patches/industry_prod.png <-- if now only the values would be != 0 ;-) 19:56:47 <andythenorth> planetmaker: I'll send you :) 19:56:54 <andythenorth> right now I am doing some work work 19:56:59 <andythenorth> so can't discuss much 20:22:07 *** frosch123 has quit IRC 20:28:44 *** JVassie has joined #openttdcoop.devzone 20:37:42 <planetmaker> hm, I guess i need to tune the supplying formula... but at least variables are now correctly displayed 20:49:50 <V453000> supplies being reworked? nice :)) 20:56:03 <planetmaker> hehe. I just installed efficiency levels: Japanes, British, Russian, American :-P 20:56:10 <planetmaker> best ... worst :-P 20:57:06 <planetmaker> http://devs.openttd.org/~planetmaker/patches/industry_prod.png 20:58:09 <Hirundo> As a bonus the 'chinese' variant should be available, which replaces supples with manual labour (ie pax) 20:58:32 <planetmaker> :-D 20:58:42 <andythenorth> that would be indian 20:58:47 <andythenorth> china has mechanised extensively 20:59:09 <andythenorth> http://www.railpictures.net/viewphoto.php?id=282067 20:59:10 <Webster> Title: RailPictures.Net Photo: Jalainur Opencast Railway SY at Jalainur, China by phil cotterill (at www.railpictures.net) 20:59:25 <andythenorth> http://www.railpictures.net/viewphoto.php?id=282125 20:59:26 <Webster> Title: RailPictures.Net Photo: Jalainur Opencast Railway SY at Jalainur, China by phil cotterill (at www.railpictures.net) 20:59:30 <Hirundo> iindia is probably more appropriate indeed, but well... you get the point :P 20:59:35 <planetmaker> anyway... output somehow changes sometimes... dunno why 20:59:52 <planetmaker> but that's for another day. Good night 21:00:01 <andythenorth> good night 21:00:10 <Hirundo> goodnight 21:08:07 <Yexo> planetmaker: reacting on your 100_extra_text.diff: 21:08:31 <Yexo> first code in STR_EXTRA_PRIMARY is {STRING}, so the to the first two bytes on the stack (=temp storage 0x100+) should be a string 21:08:40 <Yexo> however you do STORE_TEMP(LOAD_PERM(var_supply_storage), 256) which is not a string 21:11:36 <Yexo> planetmaker: I can take a look at fixes that last diff, but could you provide a full diff for the other changes? (or commit them) 21:13:25 <planetmaker> Yexo: that dir contained the full patch queue 21:13:43 <Yexo> yes, I was just being lazy :p 21:13:47 <Yexo> ok, I'll apply all of them 21:14:19 <planetmaker> well, probably it's not worth looking at it 21:14:29 <planetmaker> not including the string that way, but another string normally works 21:15:08 <Yexo> there are a few ways you can do this 21:15:36 <planetmaker> http://devs.openttd.org/~planetmaker/patches/all.diff 21:15:43 <planetmaker> ^ w/o recursive strings 21:17:41 <Yexo> would you prefer the recursive strings or not? 21:17:46 <Yexo> both are perfectly possible 21:18:48 <planetmaker> Recursive might safe one string or so 21:20:31 <planetmaker> so more for the exercise and proof-of-concept than the gain 21:21:01 <planetmaker> which might be nice. But... now I'm really off :-) good night 21:22:54 <Yexo> http://devs.openttd.org/~yexo/100_extra_text.diff Alternative diff 21:23:01 <andythenorth> good night 21:23:01 <Yexo> not tested yet though, going to do that now 21:23:03 *** andythenorth has left #openttdcoop.devzone 21:24:15 <Yexo> I think this approach will break at least the {P} codes used in STR_CARGO_UNIT_ENGINEERING_SUPPLIES 21:34:32 <Yexo> that diff sort-of works 21:35:08 <Yexo> the correct numbers are shown, but as I expected the {P} code inside the second STR_CARGO_UNIT_ENGINEERING_SUPPLIES is broken (the first one works "accidentally" because it's the first in the string) 21:54:47 <Yexo> planetmaker: http://devs.openttd.org/~yexo/100_extra_text2.diff I've also tried this 21:55:06 <Yexo> this one is impossible to get to work correctly due to the way OpenTTD handles NewGRF substrings 21:55:33 <Yexo> so if you use this: http://devs.openttd.org/~yexo/100_extra_text.diff you can just file a bug report on nml for not writing the plural codes correctly :p 21:57:35 *** JVassie has quit IRC 22:34:41 *** ODM has quit IRC