Log for #openttdcoop.devzone on 14th September 2011:
Times are UTC Toggle Colours
07:44:47  <Brot6> OpenGFX+ Road Vehicles - Revision 128:f62170e0310f: Fix: Correct the NewGRF description. (Terkhen) @
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) @
08:35:12  <Brot6> FIRS Industry Replacement Set - Revision 2598:983eeccb3116: Add: Hungarian translation (Brumi) (planetmaker) @
09:00:26  <Brot6> FIRS Industry Replacement Set - Revision 2599:b4043d7da450: Change: Update readme, include transl... (planetmaker) @
09:01:36  <planetmaker> ^ that was really needed ;-)
09:11:04  <Brot6> FIRS Industry Replacement Set - Feature #2736 (Closed): Hungarian Translation (planetmaker) @
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) @
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) @
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>
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> <-- hm, always?
13:27:41  <Webster> Title: Signed number representations - Wikipedia, the free encyclopedia (at
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> <-- 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 "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 "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) @
14:03:19  <Brot6> OpenGFX+ Road Vehicles - Revision 131:6e5a075906df: Add: Hungarian translation. (DXTR) (Terkhen) @
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) @
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) @
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 "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) @
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) @
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) @
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: with the patches as found in (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> <-- 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>
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...
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) @
18:27:09  <Brot6> OpenGFX+ Road Vehicles - Revision 133:495443cc04d2: Add #3078: Dutch translation. (Foobar) (Terkhen) @
18:27:09  <Brot6> OpenGFX+ Road Vehicles - Feature #3078 (Closed): Dutch translation (Terkhen) @
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>
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) -
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 -
19:17:49  <Brot6> serverpatches: compile of r22931 still failed (#2966) -
19:19:45  <Brot6> 32bpp-ez-patches: compile of r22931 still failed (#2446) -
19:45:56  <planetmaker> <-- 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>
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>
20:59:10  <Webster> Title: RailPictures.Net Photo: Jalainur Opencast Railway SY at Jalainur, China by phil cotterill (at
20:59:25  <andythenorth>
20:59:26  <Webster> Title: RailPictures.Net Photo: Jalainur Opencast Railway SY at Jalainur, China by phil cotterill (at
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>
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> 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: 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: 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

Powered by YARRSTE version: svn-trunk