Log for #openttdcoop.devzone on 28th August 2011:
Times are UTC Toggle Colours
00:00:55  <Brot6> DevZone Help Center - ttd-newgrf-dos.gpl (planetmaker) @
00:00:55  <Brot6> DevZone Help Center - ttd-noaction-nocomp.gpl (planetmaker) @
06:21:23  *** ODM has joined #openttdcoop.devzone
07:01:04  *** andythenorth has joined #openttdcoop.devzone
07:39:02  *** andythenorth has quit IRC
08:03:15  *** andythenorth has joined #openttdcoop.devzone
08:05:54  *** Alberth has joined #openttdcoop.devzone
08:27:28  <Alberth> andythenorth: there is not much use to have whitespace in front of "{}", is there?
08:29:43  <planetmaker> there isn't
08:44:13  <Alberth> hmm, trailing whitespace, another item for LordAro :)
08:44:47  * Alberth ponders fixing nml
08:45:56  *** JVassie has joined #openttdcoop.devzone
08:55:24  *** andythenorth has quit IRC
09:35:43  *** Zuu has joined #openttdcoop.devzone
09:48:48  <Alberth> Manufacturing supplies double production from other cargos. <-- s/from/of/ ?
09:50:27  <planetmaker> That is actually independent of the preposition a daring statement
09:50:42  <planetmaker> better would be "increase production"
09:51:02  <planetmaker> but it's correct to use "of"
09:51:14  <planetmaker> And industry has input cargos MNSP, A, B.
09:51:25  <planetmaker> Normally 8*A -> 6 output
09:51:31  <planetmaker> 8*B -> 6 output
09:51:48  <planetmaker> when there are MNSP present, then 8*A -> 8 output and 8*B -> 8 output
09:51:50  <planetmaker> or similar
09:52:29  <planetmaker> errm... "from" is correct
09:52:52  <planetmaker> while "of", of course is also correct
09:53:20  <planetmaker> maybe... better wording is "Manufacturing supplies increase production efficiency"
09:54:26  * planetmaker ends monolouge ;-)
09:55:13  <Alberth> quite long for such a simple question :)
09:57:03  <Alberth> any particular reason why the STR_CID_strings are split? (some are near line 70, some others near line 160)
10:00:40  *** frosch123 has joined #openttdcoop.devzone
10:01:36  <planetmaker> Oversight on my part. No other reason. They should be in one place
10:09:08  <frosch123> moin
10:10:01  <Alberth> moin frosch
10:33:31  <Brot6> FIRS Industry Replacement Set - Revision 2533:42fed223cec6: Change: Move STR_CID_ strings together. (Alberth) @
10:33:32  <Brot6> FIRS Industry Replacement Set - Revision 2534:2c501a61fd2f: Change: Update Dutch translation, (Alberth) @
11:18:36  *** andythenorth has joined #openttdcoop.devzone
11:28:52  * andythenorth ponders
11:28:59  <andythenorth> bounce #2996 - or have more patience?
11:28:59  <Brot6> andythenorth: #2996 is "FIRS Industry Replacement Set - Feature #2996: Split cargo label for Sugar Cane / Sugar Beet - #openttdcoop Development Zone"
11:45:03  <Alberth> are they two steps in a chain, or just different forms of sugar? (ie is a merge useful?)
11:46:12  <Alberth> Also, is this ok by you? (proposed by pm):
11:46:12  <Alberth> -STR_GENERIC_D0B2                                                                :{BLACK}Manufacturing supplies double production from other cargos.{}{}{STRING}
11:46:12  <Alberth> +STR_GENERIC_D0B2                                                                :{BLACK}Manufacturing supplies increase production efficiency.{}{}{STRING}
11:51:28  <planetmaker> it is. Though the string could get a better name, too ;-)
11:51:33  <planetmaker> But that might be a different patch
11:52:32  <andythenorth> the cargos are different forms of sugar
11:52:45  <planetmaker> Alberth: sugar beet and sugar cane are both ...^ raw material sugar is made from
11:52:49  <andythenorth> to give a fair chance to vehicle set authors, they need different labels
11:52:54  <planetmaker> thus for vehicles it makes sense to split
11:53:02  <andythenorth> unless we decide we don't care about that (like for supplies, goods etc)
11:53:12  <planetmaker> that's different IMHO :-)
11:53:22  <planetmaker> the supplies are the same
11:53:31  <planetmaker> but sugar beet and sugar cane do look different
11:53:51  <andythenorth> good argument
11:53:58  <andythenorth> 'supplies are supplies' in all cases
11:54:03  <andythenorth> sugar beet != sugar cane
11:54:18  <planetmaker> that was the whole argument... was there another?
11:54:40  <Alberth> planetmaker: there are other inconsistencies too MNSP vs MANUFACTURING_SUPPLIES eg
11:55:07  <Alberth> no merge of the sugar cargoes it seems
11:55:12  <andythenorth> planetmaker: there is no other argument, I just wasn't 100% clear in my mind previously
11:55:47  <planetmaker> I don't understand you argument, Alberth
11:55:47  <andythenorth> so the split has to happen prior to 0.7, or we have to at least restore the previous climate-specific strings
11:55:58  <planetmaker> mnsp are mnsp and look the same always
11:56:09  <andythenorth> Alberth: are you looking for current split of sugar in nml FIRS?
11:56:17  <andythenorth> it got removed by the migration
11:56:21  <planetmaker> andythenorth: the strings are not the difficulty / savegame breakage
11:56:44  <planetmaker> it's the cargo acceptance and production which will screw savegames
11:56:47  <andythenorth> sure
11:56:53  <andythenorth> so there are two routes here:
11:57:09  <andythenorth> 1. restore RSGR cargo to state it was in for 0.6 (lost during nml conversion)
11:57:10  <Alberth> euhm, I sort of lost both of you :)
11:57:21  <andythenorth> 2. split cargos now to avoid again breaking saves
11:57:26  <planetmaker> hm... what was lost, andythenorth?
11:57:28  <Alberth> the MNSP was about name inconsistencies in the string names
11:57:37  <planetmaker> oh. :-)
11:57:42  <planetmaker> Go right ahead there, Alberth
11:57:57  <planetmaker> the sugar discussion is about cargo _labels_ - not so much the strings
11:58:11  <planetmaker> i.e. game internal representation one cargo vs. two cargos
11:58:28  <andythenorth> the climate specific "...Cane" "....Beet' strings for RSGR were lost during nml conversion.  And the defines are inconsistent between ...CANE and ...BEET
11:58:29  <Alberth> yeah it is completely separate from string names :)
11:58:47  <planetmaker> ah, I see, andythenorth. Never noticed before :-)
11:59:00  <andythenorth> at least when I grepped code for them, that seemed to be the case
11:59:05  <andythenorth> I *didn't* actually check in game :o
11:59:13  <planetmaker> :-P
11:59:34  <andythenorth> yeah
11:59:39  <andythenorth> I have sugar cane in arctic right now
12:00:44  <andythenorth> if that hadn't been broken, I would postpone the split and accept future save break
12:00:56  <planetmaker> genetic manipulation can do wonders nowadays
12:00:57  <andythenorth> but it seems to no purpose to do work to reimplement that
12:01:29  <andythenorth> climate specific cargos are a bad pattern :P
12:01:36  <andythenorth> but that horse has bolted, so to speak
12:03:13  <planetmaker> oh, they're not really a bad pattern
12:03:21  <planetmaker> they're even there in TTO ;-)
12:03:49  <andythenorth> solving this is the kind of problem y*xo is good at
12:03:56  <planetmaker> :-)
12:04:04  <andythenorth> I suppose it might overlap with economies somewhat
12:04:11  <andythenorth> economies might need some thought
12:04:30  <andythenorth> ideally they would be 100% cb, or 100% actions 6/7/9
12:05:06  <planetmaker> let's look at the CB approach
12:05:09  <andythenorth> mixing those will make for *horrible* code, unless it can all be abstracted to templates
12:05:56  <andythenorth> cb 14b and 14c can do some of what is needed
12:06:43  <andythenorth> cb22 could control availabiilty, but industries would appear on map / fund menu
12:07:10  <andythenorth> cb28 could control probably, we'd set the action 0 props for that to 255 in all cases
12:07:19  <planetmaker> <-- should allow for industries
12:07:44  <andythenorth> cb39 could handle varying cargo payments, but it wouldn't show up in cargo payment chart
12:08:19  <andythenorth> there's no cb to enable / disable a cargo
12:09:00  <andythenorth> industry window strings are a cb anyway, so we can display different texts when needed
12:09:43  <planetmaker> nor would cargo change via CB show in the nice industry cargo flow chart IIRC
12:10:02  <planetmaker> if we don't over-do that we should be safe, though
12:10:15  <andythenorth> cargos and industries can be discussed separately imo
12:10:22  <andythenorth> cargos with a 6/7/9 is fine
12:10:57  <planetmaker> it's much more difficult to do with a 6/7/9
12:11:27  <planetmaker> what we have here is actually the prime case where this CB c/should be used.
12:11:31  <planetmaker> conceptually
12:11:40  <andythenorth> ideally yes
12:11:50  <andythenorth> we could write new cbs if they don't exist :P
12:11:57  <planetmaker> yes :-P
12:12:07  <planetmaker> though we don't really need a new one
12:12:12  <planetmaker> 14B+14C are what we need
12:12:31  <andythenorth> for industries yes
12:13:36  <planetmaker> I wonder whether we need to adjust tiles
12:13:58  <planetmaker> the tiles also need to accept the cargo, yes?
12:15:24  <planetmaker> but... we could have sugar refinery (and others where needed) just have accept both sugar types
12:15:48  <Hirundo> with NML, doing the acceptance via actions 6/7/9/D should be quite easy and works better with the cargo flowchart
12:16:11  <planetmaker> but indeed I never conceptually understood why cargo acceptance is governed by both, tiles AND industries together
12:16:22  <andythenorth> planetmaker: it just has to be :)
12:16:41  <Hirundo> Old ttd cruft, basically
12:17:08  <Hirundo> If you'd design openttd out of the blue, you'd leave acceptance to the industry to decide (as FIRS basically does)
12:17:33  <andythenorth> hmm
12:17:37  <planetmaker> well... could I set all tiles to accept nothing and industries still would accept stuff?
12:17:46  <andythenorth> stations wouldn't though
12:18:10  <planetmaker> and that ^
12:19:23  <planetmaker> Hirundo: ideally the cargo acceptance would allow a case switch
12:19:32  <planetmaker> that way we could easily implement economies.
12:19:50  <planetmaker> And that was / is the reason I argue for the CB as I could do that there
12:20:09  <planetmaker> the action6/7/9 makes a case switch much harder - unless I could write something like
12:20:48  <planetmaker> property { accepted_cargos: cargo_acceptance_switch(parameter) }
12:21:16  <planetmaker> for a if then else choice it's simple enough to use the ? operator
12:21:37  <planetmaker> but I'd like it more "future-proof"
12:22:55  <andythenorth> if we get it wrong, it's spaghetti time :P
12:23:05  <Hirundo> then economies would break the cargo flow chart even further
12:23:14  <andythenorth> conditional code everywhere, some of it run-time, some of it load-time :P
12:24:41  <planetmaker> Hirundo: I'd not mind if this switch was executed at game-start or was an action6 behind the scenes
12:25:25  <planetmaker> asked differently: how can I assign a map-generation-time variable to the accepted_cargo_types property?
12:26:42  <andythenorth> can't we just template in n action 0s?
12:26:48  <andythenorth> using generation of some kind?
12:26:58  <planetmaker> similar to the pseudo code of variable = "RSGR"; (...) property { accepted_cargo: [variable, 8]; }
12:27:22  <planetmaker> we can do that, andythenorth
12:27:39  <planetmaker> though I'm not sure it makes sense to template that
12:27:45  <planetmaker> well... maybe
12:28:18  <planetmaker> if (climate==climate_tropical) { ACCEPT_CARGOS("MNSP", "RSGR") } else { ... }
12:28:29  <andythenorth> we could use CPP or another template language, and just include every industry file n times, changing the defines
12:28:36  <andythenorth> lot of code
12:29:11  <planetmaker> no need to include it n times. Just a short template which switches for climates / another variable to have a different meaning
12:29:16  <planetmaker> maybe easiest
12:29:34  <planetmaker> hm, yes. quite easy probably
12:29:37  <andythenorth> so certain action 0 props...
12:29:43  <andythenorth> for both industry and tile
12:33:50  * planetmaker templates
12:34:07  <frosch123> andythenorth: a special example for tile vs. industry acceptance is the oilrig
12:34:19  <frosch123> the tiles accept passengers, so they get accepted and paid at the station
12:34:19  <andythenorth> good point
12:34:27  <frosch123> the industry does not, so the passngers do not ger processed
12:38:34  <Hirundo> accepted_cargo_types: [a,b,c] currently requires all entries to be constants, that could be amended though
12:41:41  <Hirundo> <- sprite order for type 02 is wrong, I think
12:41:53  <Hirundo> X-crossing should go before the underlays
12:42:06  <Hirundo> planetmaker: ^^
12:43:37  <planetmaker> hm, bad :S
12:44:23  <planetmaker> I fear you're right, though
12:47:03  <planetmaker> I can define a property of an industry several times, the last definition wins, right?
12:47:31  <planetmaker> thus one could use the normal industry declaration as default and just overwrite the value on certain conditions?
12:50:50  <Hirundo> yes, that's possible
12:51:33  <planetmaker> good. That makes it easier :-)
12:51:40  <planetmaker> In most cases we want to use default anyway
13:16:20  *** JVassie has quit IRC
13:22:11  <planetmaker> andythenorth: did you now add already two raw sugar cargos?
13:22:34  <andythenorth> not in trunk firs, no
13:22:45  <andythenorth> I started a bad patch for it - on the ticket
13:26:21  <planetmaker> I see. Thanks
13:26:40  <andythenorth> it's not much use tbh
13:38:44  <planetmaker> it's enough :-)
13:38:48  <planetmaker> sugar cane or sugarcane?
13:39:05  <planetmaker> hm, nvm
13:39:12  <andythenorth> Sugarcane according to wikipedia
13:39:41  <andythenorth> Sugar Beet
13:39:47  <andythenorth> not consistent :P
13:39:47  <planetmaker> ok
13:48:24  <planetmaker> languages are never consistent
13:51:38  *** andythenorth has quit IRC
14:01:53  <planetmaker> hm, there he goes
14:04:38  *** Zuu has quit IRC
14:18:28  <planetmaker> I need some help: <.. the last patch doesn't compile FIRS anymore with
14:18:30  <planetmaker> nmlc: "sprites/nml/industries/arable_farm.pnml", line 140: Unrecognized identifier 'SGBT' encountered
14:18:58  <planetmaker> but both, SGBT and SGCN are defined conditionally
14:19:27  <planetmaker> is it such that I cannot define labels conditionally?
14:50:02  *** ^Spike^ has joined #openttdcoop.devzone
14:51:20  <Hirundo> planetmaker: Add them to the cargo translation table
14:51:47  <planetmaker> oh... :-)
14:52:05  <planetmaker> I suspected that I missed something obvious.
14:52:19  <planetmaker> But... didn't see the wood because of the trees :-) Thanks
14:56:26  <Brot6> DictatorAI - Revision 168:ad74f06fd92c: Rails: (krinn) @
14:56:26  <Brot6> DictatorAI - Revision 169:e2ca9025f40b: Now the AI can: (krinn) @
14:56:26  <Brot6> DictatorAI - Revision 170:afc77f8c4307: - Raise funds before buying a rail station (krinn) @
15:04:38  <planetmaker> Terkhen: <-- what do you think of this way to introduce economies for cargos?
15:04:49  <planetmaker> (for now only to distinguish tropical vs. other climates)
15:08:13  <Hirundo> You might (or might not) place the defines within the item blocks, this allows not repeating the item(..) block
15:08:45  <planetmaker> an item block can have several property blocks?
15:09:02  <Hirundo> Yes
15:09:11  <planetmaker> I somewhat thought that if (...) doesn't work within item blocks. Maybe that was once, but is no more
15:09:36  <planetmaker> is a good idea, I guess
15:09:41  <planetmaker> saves some real estate
15:11:56  <Hirundo> <bbl
15:13:02  <planetmaker> is there a advantage in that?
15:22:49  <Terkhen> planetmaker: IIRC economies would also change probabilities
15:22:57  <Terkhen> and also industry appearance
15:23:33  <planetmaker> Terkhen: yes, they could. But I'd make a separate macro for that, when economies change them
15:23:54  <planetmaker> That way one can change the default values by property and economy
15:23:55  <Terkhen> and chain conditions as done in ogfx-industries?
15:24:21  <Terkhen> for example FACTORY_ENABLED could be (STEEL ENABLED || COPPER ORE ENABLED || etc)
15:25:42  <planetmaker> that might be... I'd set those conditions in header.pnml
15:26:29  <planetmaker> which I actually do now. where CARGO_ALL_TROPICAL is identical to 1 (and the cargo_param is defined there, too)
15:27:33  <Terkhen> you might want to check the file where all conditions are defined in ogfx-industries
15:27:58  <Terkhen> conditions will be different for FIRS, but IMO they should be chained and organized in a similar way
15:28:30  <planetmaker> found it. Yes, agreed
15:28:56  <planetmaker> But defining any actual condition other than "TROPICAL" is - for now - going too far
15:29:09  <Terkhen> agreed :P
15:29:48  <planetmaker> but it could be named TROPICAL_CARGOS
15:29:56  <Terkhen> yes
15:29:57  <planetmaker> or maybe even SUGARCANE_ENABLED
15:30:09  <Terkhen> if you plan to use for other tropical cargos the first, otherwise the second
15:30:13  <planetmaker> good point
15:30:48  <planetmaker> there's no immediate such plan. But sugarcane_enabled might be used better than a general tropical_industries...
15:31:09  <planetmaker> I'll change it to use such definition
15:31:12  <Terkhen> ok :)
15:42:54  *** JVassie has joined #openttdcoop.devzone
15:52:30  <frosch123> <- :s
15:54:01  <planetmaker> Terkhen: patches updated. Use the ...a_... patches
15:54:10  <Yexo> frosch123: what do the numbers mean?
15:54:10  <planetmaker> frosch123: what do the numbers show?
15:54:16  <planetmaker> :-)
15:54:18  <frosch123> number of calls in the top row
15:54:25  <frosch123> millions of cpu ticks in the second row
15:54:35  <frosch123> 512x512 map with firs
15:55:17  <Yexo> interesting that randomisation is that cpu heavy
15:55:24  <frosch123> the randomisation seems to be tileloop triggers of industry tiles
15:55:26  <planetmaker> yup
15:55:40  <frosch123> yeah, surprises me as well
15:55:40  <planetmaker> so... maybe we should reduce that
15:55:51  <frosch123> but there does not seem to be a flag to disable it
15:56:16  <frosch123> so it rather seems to mean that firs does not use expensive animation callbacks
15:56:16  <Alberth> a mersenne twister isn't it?    that's pretty heavy
15:56:17  <planetmaker> only few tiles need re-randomization, like oil wells
15:56:43  <frosch123> maybe i should run it with ecs :)
15:56:53  <planetmaker> would be an interesting comparison
15:59:45  <frosch123> <- yeah, looks more like what i remembered
16:00:55  <planetmaker> that's siginificantly heavier
16:01:09  <Yexo> frosch123: does help in any way?
16:01:18  <Yexo> probably not, but if it's really the call to Random() that is heavy it might
16:01:26  <frosch123> yeah, but if you take only the rerandomisation. ecs has more calls, but they take a lot less time
16:01:59  <Yexo> rerandomisation is basically the same as getting the normal graphics
16:05:23  <frosch123> Yexo: that diff has no effect
16:05:36  <Yexo> I suspected as much
16:06:16  <frosch123> anyway, i want to add filters for features and specific entities (engine name, industry name)
16:06:24  <frosch123> other suggestions?
16:06:39  <Yexo> filter for newgrfs?
16:06:54  <Yexo> although maybe that's not necesary if you can filter by entity already
16:07:12  <frosch123> well, it can be useful if you want to blame someone :p
16:07:59  <frosch123> i would also like to show the number of varact2 or advvaract2 operators. but i do not know where :p
16:08:01  <planetmaker> min_compatible_version?
16:08:12  <frosch123> maybe some combobox to swich what is displayed
16:08:16  <frosch123> planetmaker: what?
16:08:44  <planetmaker> hm... I guess I mis-understood the scope... filter for the timings displayed, yes?
16:09:10  <frosch123> yes
16:09:14  <planetmaker> filter by newgrf might still be good
16:10:01  <frosch123> anyway, that window needs a big screen :p
16:10:05  <planetmaker> :-)
16:10:22  <frosch123> maybe i should add a horizontal scrollbar to scroll the months
16:10:25  <planetmaker> the screenshot fit mine, so it's ok :-P
16:46:35  *** andythenorth has joined #openttdcoop.devzone
16:46:53  *** andythenorth has quit IRC
17:02:33  <planetmaker> hm...
17:21:22  <Brot6> firs: update from r2532 to r2534 done -
17:23:33  <Brot6> opengfx: update from r727 to r729 done -
17:25:10  <Brot6> Following repos didn't need a nightlies update: ogfx-trains (r251), narvs (r52), bros (r52), ogfx-industries (r123), 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 (r1639), water-features (r51), 32bpp-extra (r40), manindu (r7), newgrf_makefile
17:25:10  <Brot6> (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 (r80), ttrs (r36), ogfx-trees (r51), swedishrails (r205), grfcodec (r833), ai-aroai (r39), german-townnames (r34), smts (r19), chips (r143), belarusiantowns (r8),
17:25:13  <Brot6> indonesiantowns (r41), ailib-string (r29), airportsplus (r132), comic-houses (r71)
18:20:41  <Brot6> FIRS Industry Replacement Set - Feature #2996: Split cargo label for Sugar Cane / Sugar Beet (planetmaker) @
18:22:17  <Brot6> FIRS Industry Replacement Set - Bug #3014 (Confirmed): Enforce level ground for (some) industries (planetmaker) @
18:46:24  <Hirundo> FWIW: CBs 0x01 (random trigger) and 0x25 (anim control) are they only industry [tile] CBs that don't have a flag, so both default to the graphics CB when called
18:47:03  <planetmaker> does that matter?
18:47:04  <Hirundo> As CB01 is called for all tiles and the normal CB only for visible ones, the randomization is likely a lot more heavy (esp on large maps) even without the random calls
18:47:18  <planetmaker> ah
18:48:13  <Hirundo> Whether that is wanted behaviour (from NML POV) can be debated.. esp as there is a difference in behaviour for flagged and unflagged callbacks
18:49:48  <Hirundo> i.e. If your non-handled callback gets chained to default or not depends on if it needs a flag bit
18:53:51  <Terkhen> planetmaker: sorry, I was away
18:53:58  <planetmaker> no need to be sorry :-)
18:54:08  <planetmaker> RL is to sweet to regret it ;-)
18:54:11  <planetmaker> *too
18:55:08  <Terkhen> looks fine to me
18:59:50  <Brot6> FIRS Industry Replacement Set - Revision 2535:62d0325bd50d: Change #3014: Enforce level ground fo... (planetmaker) @
19:02:32  <planetmaker> hm, I'll leave the change of cargo labels until andy reviewed it, too
19:03:43  <Brot6> FIRS Industry Replacement Set - Revision 2536:f780a966b143: Add: Templates for industry cargo acc... (planetmaker) @
19:03:43  <Brot6> FIRS Industry Replacement Set - Revision 2537:4309b51581e5: Fix: Raw sugar is sugarcane in tropic... (planetmaker) @
19:03:48  <Brot6> clientpatches: compile of r22852 still failed (#2964) -
19:05:45  <planetmaker> Terkhen: do you also have an opinion on the fence templates?
19:06:01  <planetmaker> basically it duplicates the spritelayout templates to introduce new ones which also support fences
19:06:36  <planetmaker> they're used the same way, named the same way except s/SPRITELAYOUT/SPRITELAYOUT_FENCES/g
19:07:15  <planetmaker> and it adds a few macros which allow to define where and when fences are drawn
19:08:58  <Brot6> openttd-vehiclevars: update from r22851 to r22852 done -
19:09:09  <planetmaker> which industries have to use when they want fences
19:10:48  <Brot6> serverpatches: compile of r22852 still failed (#2966) -
19:12:19  <Brot6> 32bpp-ez-patches: compile of r22852 still failed (#2446) -
19:20:24  <Terkhen> do you have code? or is it already committed?
19:27:09  <Brot6> FIRS Industry Replacement Set - Bug #3014: Enforce level ground for (some) industries (planetmaker) @
20:17:42  *** JVassie has quit IRC
20:18:53  *** JVassie has joined #openttdcoop.devzone
20:43:49  *** frosch123 has quit IRC
20:56:02  *** Alberth has left #openttdcoop.devzone
20:58:58  *** andythenorth has joined #openttdcoop.devzone
21:01:25  *** JVassie has quit IRC
21:14:09  *** JVassie has joined #openttdcoop.devzone
21:17:42  <Ammler> orudge: where are zernebook servers located? Possible to use as "video" proxy for us tv?
21:23:49  <planetmaker> uk and us afaik, Ammler
21:28:36  <orudge> Ammler: We do have some servers in the US
21:29:58  <Ammler> also for sale? (roots)
21:30:30  <Ammler> or virtual whatever
21:30:33  <orudge> well
21:30:44  <orudge> our VPSes are based on our European servers, we just have US servers for shared hosting at preset
21:30:51  <orudge> if you just want to run a proxy server, though, we might be able to do something
21:31:51  <Ammler> well, first I wonder if such such proxies work
21:31:55  *** andythenorth has quit IRC
21:32:49  <Ammler> and how much something like that would cost
21:33:04  <orudge> I guess it would depend on what you wanted to use
21:33:13  <orudge> and in this case, I'd probably charge a small fee plus any bandwidth you used
21:33:50  <Ammler> the video streams from the tv websites are just http, right?
21:43:08  <planetmaker> that *might* be interesting to have a proxy ;-)
21:43:33  <Ammler> well, currently I use torrents as "proxy"
21:43:54  <Ammler> they are mostly damn fast to provide a torrent
21:44:54  <planetmaker> I'd even buy it, but they don't have game of thrones in iTunes... :S
21:46:01  <Ammler> oh, I love those series
21:46:30  <Ammler> also ROM or Spartacus
21:46:47  <Ammler> The Tudors
21:47:38  <Ammler> Deadwood
21:48:14  <Ammler> I watched those mostly twice, original and synced
21:49:16  <Ammler> well, "game of thrones" might be another kind of tv but still
21:54:11  *** andythenorth has joined #openttdcoop.devzone
22:05:37  <Yexo> Hirundo: there is another problem with rerandomisation: it'll only rerandomize when the random action2 is reached by the "default" graphics chain
22:05:58  <Yexo> in other words if you use a random action2 only for some callback it's never rerandomized
22:06:53  <Yexo> so perhaps NML should (invisible to the user) create another "callback handler" for cb1 that chains to a chain that only contains one or more random action2's that contain the same bits as the random action2's used (even indirectly) by the same item
22:07:37  <Yexo> that means that cb1 will become a lot faster (since no lengthy processing) and works in all cases without having to explain a troublesome workaround to nml users
22:52:15  *** ODM has quit IRC
23:44:27  *** JVassie has quit IRC

Powered by YARRSTE version: svn-trunk