Log for #openttdcoop.devzone on 16th August 2010:
Times are UTC Toggle Colours
00:11:35  *** KenjiE20 has quit IRC
00:38:48  *** Seberoth has quit IRC
06:10:43  *** frosch123 has joined #openttdcoop.devzone
06:35:10  *** ODM has joined #openttdcoop.devzone
08:10:16  *** ODM has quit IRC
09:10:36  *** ODM has joined #openttdcoop.devzone
09:30:54  *** Seberoth has joined #openttdcoop.devzone
10:26:31  *** andythenorth has joined #openttdcoop.devzone
10:34:21  *** FooBar has joined #openttdcoop.devzone
10:35:10  <FooBar> andythenorth here?
10:41:45  *** KenjiE20 has joined #openttdcoop.devzone
11:36:02  *** FooBar has quit IRC
11:37:09  <Ammler> damn stupid svn
11:38:15  <Rubidium> it's being stupid in what way?
11:40:27  <planetmaker> stupid as in offline
11:40:42  <planetmaker> that is
11:41:04  <Brot6> Autopilot - Feature #1251 (Assigned): convert to hg (Ammler) @
11:41:04  <Brot6> Autopilot - Feature #1252 (New): integrate the custom commands (Ammler) @
11:42:50  <Ammler> stupid as in no "automatic" backup :-)
11:43:09  <planetmaker> :-)
11:43:20  <planetmaker> clear advantage of hg: everyone has a backup
11:43:51  <Ammler> yes, and you can safely continue work until the "central" server is available again
11:44:56  <planetmaker> well. I'm sure there's a backup of the svn. But... that's probably with Osai, too ;-)
11:44:57  <Ammler> I wonder, if we should convert everything to hg from our svn :-/
11:45:26  <Ammler> I assume, the svn repo is even there, just not working
11:47:31  <Rubidium> if you need none of the features of svn, then there's not much reason not to I'd say
11:48:03  <planetmaker> what is your reason for svn, except the fixed revision number?
11:48:26  <Ammler> control of commits
11:48:57  <Ammler> time and number should be in order
11:49:55  <Ammler> fixed rev number is only a adv. against git, not generic DVCS
11:50:55  <Ammler> (if you have a kind of master repo :-)
11:53:32  <Ammler> well, with hooks, you might be able to have every adv. of svn also with hg
12:24:43  <Brot6> OpenGFX - Bug #280: standard signals (2006TTD) @
12:36:28  <Brot6> OpenGFX - Bug #280: standard signals (Ammler) @
12:41:43  <Brot6> OpenGFX - Bug #280: standard signals (2006TTD) @
12:42:55  <Brot6> OpenGFX - Bug #280: standard signals (Ammler) @
12:44:29  <Brot6> OpenGFX - Bug #280: standard signals (Ammler) @
12:54:27  <Brot6> OpenGFX - Bug #280: standard signals (2006TTD) @
13:00:06  <Brot6> Unable to connect to Failed with 502 Bad Gateway
13:07:03  <Brot6> Unable to connect to Failed with 502 Bad Gateway
13:07:56  <planetmaker> ?
13:09:57  <Rubidium> why oh why did you ever by a gateway computer?
13:14:02  <Brot6> Unable to connect to Failed with 502 Bad Gateway
13:21:02  <Brot6> Unable to connect to getaddrinfo: Temporary failure in name resolution
13:21:16  <planetmaker> ?!
13:24:07  <Ammler> hmm
13:24:41  <Ammler> reboot issued
13:26:23  *** Brot6 has quit IRC
13:26:45  *** andythenorth has quit IRC
13:26:52  *** Ammler has quit IRC
13:26:52  *** Hirundo has quit IRC
13:26:52  *** V453000 has quit IRC
13:26:57  *** Terkhen has quit IRC
13:30:59  <frosch123> peace
13:31:06  *** Hirundo has joined #openttdcoop.devzone
13:31:09  *** Brot6 has joined #openttdcoop.devzone
13:31:34  *** Ammler has joined #openttdcoop.devzone
13:33:02  *** Terkhen has joined #openttdcoop.devzone
13:34:04  *** V453000 has joined #openttdcoop.devzone
13:34:32  *** andythenorth has joined #openttdcoop.devzone
13:44:06  <Ammler> planetmaker: would you code the signals like they are now?
13:46:59  <planetmaker> In principle yes. The signals are an improvement
13:47:17  <planetmaker> And they're acceptably arranged
13:47:33  <planetmaker> at least from a first look
13:48:02  <planetmaker> I'd propose to make the distinctive bars one pixel wider or higher
13:48:15  <planetmaker> maybe even two, one each direction
13:50:38  <Ammler> you need to code every single sprite, or do you see a use of a template?
13:53:50  <planetmaker> I see a use for a template which covers one signal type - and then can be re-used for the others
13:54:15  <planetmaker> Or is it not that regular that each signal type is in its own horizontal arangement, the same as the others?
13:54:58  <planetmaker> At least I'd try to get that done
13:55:25  <planetmaker> NML templates are so much more flexible ;-)
13:55:55  <planetmaker> I'm reluctant though to start introducing NML as an OpenGFX dependency as long as it has no release
13:56:08  <planetmaker> OpenGFX is too important
13:56:52  <planetmaker> and maintainers wouldn't like that at all, I guess
14:01:44  <Ammler> hmm, well, that means mostly rearrange the signals :-P
14:02:43  <planetmaker> that's I guess the sour apple which needs to be eaten
14:03:05  <Ammler> yes, that is like code every single sprite... almost
14:03:49  <planetmaker> hm... "one has to bite the bullet" or "one has to swallow the pill" is the translation of "in den sauren Apfel beißen müssen"
14:03:49  <Ammler> hmm
14:04:24  <Ammler> the sizes of the sprites are different
14:04:25  <Rubidium> planetmaker: just call it Dunglish and it's okay as well :)
14:04:26  <planetmaker> or "grasp the nettle" or "grin and bear it"
14:04:38  <Ammler> that is hell on coding
14:04:45  <planetmaker> Ammler, that sucks.
14:05:10  <planetmaker> Though I guess there's not much around that.
14:05:19  <planetmaker> hehe @ Rubidium :-)
14:05:42  <Ammler> the question is, do we do that self or ask 2006TTD to make a nice templateish spriteset
14:06:03  <planetmaker> it's probably quicker to do oneself
14:06:15  <planetmaker> Before you communicated all the constraints, you're done
14:06:38  <Ammler> well, it isn't just this, it is also the uk semaphores
14:06:43  <planetmaker> Otherwise one will have to supply the template in advance, I guess
14:06:48  <planetmaker> yes
14:07:29  <Ammler> maybe the easiest would be to rearrange the sprites in the existing pcx?
14:07:43  <Ammler> so we can keep the code
14:07:57  <planetmaker> maybe. But I'd not prefer it. It's several and HUGE pcx
14:08:11  <planetmaker> Once pcx per type would be nice
14:08:14  <Ammler> yes, cut the signals out there
14:08:28  <Ammler> adjust ypos
14:08:42  <planetmaker> Just create a template large enough for all signals
14:08:50  <Ammler> but keep xpos and sizes and offsets
14:08:53  <planetmaker> and then colour-select the signals and paste them
14:09:04  <planetmaker> new template :-)
14:09:13  <planetmaker> the copy&paste you propose is nearly as much work
14:09:34  <Ammler> you need to rearrange the sprites in both cases, mostly
14:09:47  <planetmaker> yes. That's why a clean new solution is better
14:09:52  <planetmaker> One pcx per type
14:10:00  <planetmaker> in a common template
14:10:04  <Ammler> well, with a template you also need to code it
14:10:08  <planetmaker> it's a bit graphical copy&paste, but feasable
14:10:10  <Ammler> to test ingame etc
14:10:23  <planetmaker> of course
14:10:28  <planetmaker> but you need to do that anyway
14:10:36  <Ammler> that is all given, if you use the existing spriteset
14:11:53  <planetmaker> well. If you want to put them into OpenGFX, you do it your way :-)
14:12:21  <Ammler> I would like the templatish way
14:12:25  <planetmaker> Mostly I'd like to see the signals in a separate graphics file
14:12:37  <Ammler> but I am quite unsure because of the different sizes
14:12:55  <planetmaker> make a large box which fits each of them
14:13:08  <planetmaker> then define the place the post's foundation will be
14:13:26  <planetmaker> then copy them all into that template, adjusting their foundation to the pre-defined foundation pixel
14:13:39  <planetmaker> Then it *should* work for all with one alignment.
14:14:07  <Ammler> does nml support Action5?
14:19:05  <planetmaker> it does support all actions afaik
14:19:27  <planetmaker> but there may be cases which have not been tested or completely implemented so far
14:36:38  <Ammler> happy birthday debian :-)
14:57:16  <DJNekkid> planetmaker: bridge overlays = std overlays? :)
14:57:20  <DJNekkid> (usually)
14:57:47  <planetmaker> yes
14:58:04  <planetmaker> at least I did so
14:58:17  <DJNekkid> bridge surface atleast :)
14:58:31  <DJNekkid> action3, cargo 6 :)
14:59:41  <planetmaker> yes, but same sprites basically
14:59:58  <DJNekkid> aye :D
15:00:02  <planetmaker> though I used not the overlay, but underlay
15:01:07  <DJNekkid> oki... :D
15:01:24  <DJNekkid> *changes a 01 to a 02*
15:05:17  <DJNekkid> hmm, i guess it dont follow the same pattern :(
15:19:47  *** frosch123 has quit IRC
15:20:49  <Brot6> OpenGFX - Bug #280: standard signals (2006TTD) @
15:21:33  <Ammler> TBRS without tracks would be a nice set, wouldn't?
15:25:03  <V453000> it is nice already :p
15:26:46  <DJNekkid> tbrs?
15:26:57  <V453000> total bridge renewal set?
15:27:18  <DJNekkid> right :D
15:27:21  <V453000> :)
15:28:01  <DJNekkid> but: i have TBRS installed, and R93 of nutracks adds the proper sprites to the bridges
15:28:14  <V453000> :)
15:28:21  <V453000> swedish rails do that too
15:28:49  <DJNekkid> :D
15:28:53  <Brot6> Nutracks - Revision 93:8afb91796072: Add: Brige overlays :D (DJNekkid) @
15:28:57  <DJNekkid> ^^
15:29:28  <V453000> btw I have a question about 2cc set ... is it intentional that 4th gen wagons have utter Zero weight when empty? :O and why do they carry 60 tonnes
15:29:41  <DJNekkid> what version?
15:29:55  <V453000> v2 betas
15:30:37  <DJNekkid> im not 100% on beta3, but the latest revs have weight on them
15:30:57  <V453000> ok :)
15:30:57  <DJNekkid> i did a "balance" thing on the wagon some time ago, and i think it were in beta3?
15:31:12  <V453000> beta3 has still zero I think
15:31:19  <V453000> but whatever, if it is fixed in the latest ones :)
15:31:30  <V453000> but why the extreme cargo capacity? it is boring :)
15:31:51  <DJNekkid> either way, beta3 have weight
15:31:56  <V453000> oh
15:31:57  <V453000> ok :)
15:32:43  <DJNekkid> and the ealier wagons have its capacity reduced, and adjusted for length
15:32:57  <V453000> well earlier ... but not later
15:33:03  <DJNekkid> for example 10% lower capacity if it were equally long
15:33:13  <V453000> I know
15:33:22  <V453000> but you usually care about the best :)
15:33:44  <DJNekkid> but if its 2/8ths shoter its adjusted accordingly
15:34:52  <V453000> well I have no issue with that :) I am rather trying to find out the reason why to differ completely in the total cargo capacities :)
15:35:01  <V453000> from the other newGRFs :)
15:35:26  <DJNekkid> the usset have rather high capacaties as well
15:35:30  <V453000> 40
15:35:34  <V453000> same as DB :)
15:35:45  <DJNekkid> but if you feel they are too high, i might take that into concideration
15:35:47  <V453000> well only goods are higher ... but goods are reasonable
15:35:52  <V453000> I definitely do :)
15:36:08  <V453000> 30 is normal, 40 is quite high ... I take 60 as nonsense :)
15:36:33  <V453000> the 2cc v1 had 49 which was imo the cap
15:37:04  <DJNekkid> i guess im trying to include the "worse" engines as well, to make feeders and such
15:37:32  <DJNekkid> but i can reduce the capacaties i guess..
15:38:24  <DJNekkid> got any links on a modern, say, hopper?
15:38:34  <V453000> links?
15:38:51  <DJNekkid> ? :P
15:39:32  <DJNekkid> and tbh, im not REALLY statisfied with the 2cc wagons :(
15:39:44  <V453000> well that is another thing :)
15:40:21  <DJNekkid> i dont REALLY like all of the gfx
15:41:58  <V453000> with the link you mean showing some other newgrf sets? or just some advices from myself? :o
15:42:31  <DJNekkid> advice is always conciderd nice :D
15:43:27  <V453000> well I wouldnt go above 40 tonnes of capacity for the final wagons of cargo... passengers are quite flexible so there it doesnt really matter
15:44:36  <DJNekkid> the mus have real capacties :)
15:45:14  <V453000> well I consider it from the gameplay side ;) I really give no interest to the reality in that matter
15:45:19  <planetmaker> V453000: I guess he was asking for the things as found in RL
15:45:24  <planetmaker> How much such wagon can load :-)
15:45:28  <V453000> I se
15:45:30  <V453000> e
15:45:37  <DJNekkid> planetmaker: spot on
15:45:48  <V453000> :)
15:46:15  <V453000> I just play the game, I have no clue what are the stats of real trains
15:46:44  <DJNekkid> all 2cc trains have real stats
15:46:50  <DJNekkid> except a few that have guesstiamtes
15:46:58  <DJNekkid> guesstimates
15:47:33  <V453000> hmm :(
15:47:45  <V453000> 60 tonnes still sucks :P
15:48:00  <planetmaker> hehe. I guess I said it already: don't use it ;-)
15:48:19  <DJNekkid> dont use what?
15:50:23  <planetmaker> DJNekkid: if one doesn't like large capacity, one can use the lower-capacity wagons :-)
15:50:45  <DJNekkid> hehe, indeed :D
15:50:56  <V453000> ...
15:53:25  <DJNekkid> gen 3 have 40-49unit area :D
15:53:27  <DJNekkid> same gfx
15:54:13  <V453000> that is about the top already
15:58:03  <DJNekkid> made a poll on the dev thread :)
16:18:26  <Brot6> firs: compile of r1190 failed -
16:18:36  <Brot6> newgrf_makefile: compile of r127 failed -
16:18:42  <Brot6> nutracks: compile of r93 failed -
16:18:50  <Brot6> Following repos didn't need a nightlies update: 2cctrainset (ERROR r580), 32bpp-extra (r38), airportsplus (r52), basecosts (r20), comic-houses (r71), fish (r386), grfcodec (r228), heqs (r371), metrotrackset (r54), nforenum (r469), nml (r670), ogfxplus (r41), opengfx (r482), openmsx (r97), opensfx (r97), snowlinemod (r15), swedishrails (r141), transrapidtrackset (r15), worldairlinersset (r659)
16:19:00  <Brot6> 2cctrainset: compile of r580 failed -
16:19:38  <Ammler> DAMN!
16:25:54  <DJNekkid> both 2cc and nutracks failed?
16:29:20  <Rubidium> looks more like the compile farm failed
16:29:41  <DJNekkid> oh... good ... for me
16:29:57  <Ammler> 2cc does fail without
16:30:07  <Ammler> but the rest, yes might be cf fault
16:31:09  <Brot6> nutracks: compile of r93 failed -
16:31:52  <Ammler> something with keys broken :-(
16:42:02  <planetmaker> keys?
16:47:05  <Ammler> keys of the rpms
16:47:13  <Ammler> running the compile with suse 11.3 now
16:48:15  <Brot6> firs: update from r1177 to r1190 done (7 errors) -
16:48:34  <Brot6> newgrf_makefile: update from r124 to r127 done -
16:49:17  <Brot6> nutracks: update from r92 to r93 done (13 errors) -
16:49:25  <Brot6> Following repos didn't need a nightlies update: 2cctrainset (ERROR r580), 32bpp-extra (r38), airportsplus (r52), basecosts (r20), comic-houses (r71), fish (r386), grfcodec (r228), heqs (r371), metrotrackset (r54), nforenum (r469), nml (r670), ogfxplus (r41), opengfx (r482), openmsx (r97), opensfx (r97), snowlinemod (r15), swedishrails (r141), transrapidtrackset (r15), worldairlinersset (r659)
16:49:52  <Brot6> 2cctrainset: compile of r580 failed -
16:50:05  <Ammler> DJNekkid: that is a real one :-)
16:51:15  <Rubidium> tss... can't it still not get a working GRF when some pcxes are missing? What a stupid system :)
16:52:08  <Ammler> yeah, it should pull the missing files from the people
16:53:55  <planetmaker> haha
16:57:28  <Ammler> DJNekkid: the problem with overlay is that you still have the other tracks below, which in some cases can look silly
16:57:33  <Ammler> glitchy*
16:58:07  <planetmaker> yes. That's the reason I used the underlay instead ;-)
16:58:30  <Ammler> hmm?
16:58:52  <Ammler> I guess I have ser in mind :-)
16:59:08  *** frosch123 has joined #openttdcoop.devzone
16:59:12  <planetmaker> :-)
16:59:19  <Ammler> with glitchy :-P
16:59:41  <planetmaker> does SER have glitches?
16:59:56  <planetmaker> it shouldn't ... :-(
17:00:08  <Ammler> :-)
17:00:22  <planetmaker> please report them and I'll again edit the bridge overlay sprites ;-)
17:00:24  <Ammler> well, I assume your "underlay" was a joke?
17:00:30  <planetmaker> not really
17:00:51  <planetmaker> it has kinda tracks
17:00:55  <planetmaker> and has to have
17:01:06  <Ammler> oh, so you have special overlay tracks for the briges?
17:01:39  <planetmaker> I don't recall. But I might have tuned the default ones slightly
17:01:50  <planetmaker> I did at least edit quite a bit for the level crossings
17:02:00  <planetmaker> let's see...
17:02:45  <planetmaker> hm... no. No special sprites
17:02:55  <planetmaker> But I'd add them, if the default ones glitched
17:03:42  <Ammler> maybe I saw a earlier version
17:03:50  <Ammler> I need to check that again
17:04:23  <planetmaker> <-- the first two lines of sprites serve well
17:05:14  <planetmaker> if you find it, please make a bug report
17:06:05  <Ammler> shouldn't you use the last row
17:06:08  <Ammler> without pavement
17:06:33  <planetmaker> not for bridges
17:06:54  <Ammler> pavement should be part of bridges
17:07:45  <planetmaker> Ammler: yes, *should*
17:07:49  <Ammler> :-)
17:07:53  <planetmaker> But there's no bridge which does that
17:08:00  <planetmaker> So I have to overdraw the existing tracks.
17:08:00  <Ammler> maybe it is that then, so nvm
17:08:04  <planetmaker> As such: with pavement
17:08:19  <Ammler> oh, you could manage that?
17:08:39  <Ammler> so if the bridgeset would be without tracks, you could use the others?
17:08:43  <planetmaker> If there should ever be a bridge set with good railtypes support, then I might make there a conditional check for that ans supply better sprites
17:08:51  <planetmaker> yes, I could and would
17:09:17  <planetmaker> But I'd need to check for that newgrf
17:09:24  <Ammler> then my dream for a TBRS without tracks isn't that bad :-)
17:09:32  <planetmaker> nope, not at all.
17:09:50  <planetmaker> Though I *think* that it's missing some callback for bridges
17:13:31  <Ammler> wouldn't solve a bridgeset without tracks solve all newgrf mix issues?
17:14:06  <planetmaker> not quite: it would fail, if there's no railtypes ;-)
17:14:19  <planetmaker> And I don't know how that problem can be solved
17:14:24  <Ammler> which?
17:14:40  <Ammler> or "when" isn't railtypes there?
17:14:59  <planetmaker> Just imagine only TBRS, but no railtypes activated
17:15:05  <planetmaker> then there'd be rail bridges w/o rails
17:15:13  <Ammler> ah well
17:15:29  <Ammler> you have the opengfx tracks as default
17:15:44  <planetmaker> but not on tbrs bridges
17:15:59  <Ammler> ?
17:16:04  <Ammler> now, I am confused
17:16:45  <planetmaker> I don't quite know what a bridge set can or can't do
17:17:03  <planetmaker> What it would need to know is: am I a railtypes bridge or just a default road / rail bridge
17:17:11  <Ammler> basically replace the existing bridges?
17:17:13  <planetmaker> I don't know whether that can be deduced right now
17:20:12  <Ammler> I thought, railtypes does already support bridgeset?
17:23:13  <planetmaker> railtypes specify track sprites for bridges
17:23:35  <planetmaker> but the bridge has to not draw the tracks as they do now
17:23:48  <planetmaker> so... there's a lack of railtypes support on the bridge sites
17:23:57  <Ammler> yes, but why does that fail, if you make a bridge set without tracks?
17:24:10  <planetmaker> then it doesn't fail
17:24:51  <planetmaker> What I don't quite know, but fear is: a bridge does not know about railtypes
17:25:08  <planetmaker> so a bridge set either: supplies no tracks at all or it supplies tracks
17:25:38  <planetmaker> if it doesn't supply tracks it will provide funny bridges for vanilla openttd
17:27:08  <Ammler> butbut
17:27:25  <Ammler> you make a empty bridgeset with the default tracks as railtypes
17:27:46  <Ammler> then those should be replaced by a railtypes set, shouldn't?
17:27:57  <planetmaker> yes
17:28:07  <planetmaker> But that means you have a railtypes newgrf ;-)
17:28:21  <Ammler> yes, what's the issue?
17:28:46  <planetmaker> vanilla openttd has no railtypes activated
17:29:05  <planetmaker> so for a bridgeset to work that way it needs to define 4 railtypes, the default ones
17:29:13  <Ammler> yes
17:29:17  <Ammler> and?
17:30:11  <planetmaker> That's a non-trivial thing :-)
17:30:20  <planetmaker> That's 3x as much as SE rails
17:30:42  <planetmaker> So basically it'd be a trackset with some bridges
17:31:26  <Ammler> hmm, I thought, the big part on ser is the support for non-railtypes
17:31:41  <planetmaker> it is a big part
17:31:59  <planetmaker> counting sprites maybe most actually
17:32:32  <planetmaker> but what I say is: the problem is that one actually HAS to (re-)define all default track types
17:32:32  <Ammler> for railtypes, it is just that spriteset you pasted
17:32:36  <planetmaker> if one doesn't do that, you'll have bridges w/o tracks
17:32:58  <Ammler> you have of course the railtypes in the same newgrf
17:33:04  <planetmaker> no. You need all the level crossings
17:33:33  <planetmaker> which you can simplify a lot, if you use the default ones which are neither snow-aware nor aware of the driving side and symmetric
17:35:06  <planetmaker> but otherwise you're right: one can do with the sprites I pasted, use generic level crossing sprites (except for the track part) and be done
17:35:24  <planetmaker> Might be worth to do that in OpenGFX+ ;-)
17:35:31  <planetmaker> Or better separately
17:35:39  <Ammler> in TBRS2
17:35:47  <planetmaker> yes and no
17:35:53  <Ammler> :-)
17:36:07  <planetmaker> it could be used by any bridge grf. So it's not sensible to make it directly into that
17:36:24  <planetmaker> But to require it. Like: this bridge set will only activate itself, if you also add this grf
17:36:34  <planetmaker> that's IMHO then the better solution
17:36:49  <planetmaker> as any bridge set could do that. All in all work saved then
17:37:28  <Ammler> hmm, but opengfx+ could maybe make the same with the default bridges
17:37:45  <Ammler> or maybe better opengfx_extra?
17:38:27  <Ammler> (and openttd.grf) :-)
17:39:31  *** Seberoth has quit IRC
17:40:56  <andythenorth> foobar?
17:40:57  <andythenorth> no
17:42:16  <Ammler> planetmaker: if you make the railtypes grf seperate, then people would need to know it
17:42:46  <Ammler> so adding it directly to the bridgeset is a requirement, isn't?
17:42:58  <Ammler> you can of course still supply those splitted
17:43:20  <planetmaker> Ammler: making it know is not bad
17:43:29  <planetmaker> It solves for example road set incompatibilities
17:43:36  <planetmaker> so it has a right of existance on its own
17:48:52  <planetmaker> DJNekkid: your poll in the 2cctrainset reads like "Do you want coffee or tea? Yes / No / Maybe, if..."
18:49:20  *** FooBar has joined #openttdcoop.devzone
18:49:31  <FooBar> hi all
18:52:45  <planetmaker> hi FooBar
18:57:39  <Rubidium> planetmaker: I'd answer maybe on your interpretation of the question
18:58:23  <planetmaker> :-)
18:58:33  <planetmaker> I'd answer 'yes'
18:58:55  <planetmaker> The capacity is ok or not ok. One is always true ;-)
19:08:25  <Brot6> FIRS Industry Replacement Set - Revision 1191:88bb608c8d5b: Codechange: gas station doesn't use T... (foobar) @
19:43:25  <Brot6> FIRS Industry Replacement Set - Revision 1192:1b30e83d756c: Feature: Blacksmith basic code and no... (foobar) @
19:49:01  <planetmaker> frosch123: I guess it'd be evil to add the default rails as railtypes to the extra newgrf, right?
19:49:08  <planetmaker> as it'd forbid sprite replacement?
19:49:38  <planetmaker> background of the question: bridges
19:49:51  <planetmaker> currently a base set has to supply them with tracks
19:50:07  <planetmaker> but then every other railtype newgrf has to overdraw the existing tracks
19:50:27  <planetmaker> same would - afaik - also be true for a bridge newgrf
19:50:39  <planetmaker> flaws in this logic?
19:52:42  <frosch123> i guess railtypes in the extra grf are a bit too much. canals/rivers are already very border line
19:52:56  <planetmaker> :-)
19:53:23  <planetmaker> if two newgrf define the same railtype: the 2nd one wins?
19:53:24  <frosch123> at first glance i would guess it desyncs if the game has elrail disabled
19:53:49  <planetmaker> hm... is that switch availabe to newgrfs?
19:54:54  <planetmaker> could one declare such newgrf static?
19:55:10  <planetmaker> despite it having action 1/2/3?
19:56:28  <frosch123> isn't there some other way? like marking the bridges as: draw overlay
19:56:56  <frosch123> i am not sure how the default bridges look like, but there are also single rails without ground for the default rails
19:56:57  <planetmaker> frosch123: is that possible?
19:56:59  <frosch123> even sloped
19:57:21  <frosch123> planetmaker: it would need some trickery to disable it if some other grf provides bridgesprites
19:57:52  <frosch123> but i have no idea how it would look like :)
19:57:55  <planetmaker> well. The problem I want to solve actually is indeed bridges: drawing not the default tracks, if a railtyps newgrf uses it
19:58:35  <planetmaker> that'd allow for really nice bridges. Like cantilever where one could look through or so :-)
20:00:21  <frosch123> well, but it still fails for default graphics
20:00:37  <planetmaker> well. Exactly my problem :-)
20:00:45  <planetmaker> I need bridges to know it
20:01:02  <frosch123> so, i guess: there should be some flag for bridges that they do not provide any tracks and need an overlay. and they are only part of ogfx+
20:01:08  <planetmaker> Either I have nice railtype bridges - but then no track, if there should be just vanilla OpenTTD + bridge
20:03:40  <planetmaker> hm... yes, something like that.
20:03:51  <planetmaker> Ok, but so far it's not yet possible, I guess
20:04:00  <planetmaker> And I'm not just missing it?
20:04:44  <Brot6> 32bpp-ez-patches - Revision 47:cfd60f238883: Fix: better recoloring of tile selector sprites (bas... (GeekToo) @
20:08:33  <frosch123> well, you are lucky that the extra grf is not checked for "static"-able, else the rivers would already disable it :p
20:09:30  <frosch123> however, i remember some bridge grfs which have very rail-specific bridges (e.g. the one with only the monorail track and "no bridge otherwise"
20:13:32  <Ammler> :-o openttd.grf is not static?
20:14:00  <Ammler> oh, opengfx extra isn't :'-(
20:16:29  <Ammler> well, planetmaker, as you already said, we would still have the issue with road crossing
20:17:58  <Ammler> frosch123: I would consider that as a bug of openttd, if you disable a grf, which doesn't desync
20:18:43  <Ammler> always assumed the extra _is_ static
20:18:52  <Brot6> FIRS Industry Replacement Set - Revision 1193:46ba4a71faa7: Feature: Windmill basic code and no g... (foobar) @
20:18:53  <frosch123> well, there is no point to disable it after a desync, is there?
20:18:57  <frosch123> :p
20:19:16  <frosch123> Ammler: sure, the extra is static
20:19:17  <Ammler> no, you disable it to prevent one
20:19:31  <frosch123> but it does not need to pass the static-safe check
20:19:41  <frosch123> (which opengfx would not pass)
20:20:05  <Ammler> yes, but that static-safe check does fail
20:20:13  <Ammler> since opengfx extra is desync safe
20:20:33  <frosch123> as i said, rivers are very borderline
20:20:43  <frosch123> currently they are staticsafe
20:20:45  <Ammler> or what other "rules" have you for static?
20:21:40  <Ammler> maybe we should move those to opengfx+ then
20:22:16  <planetmaker> hm... I just saw that in principle snowy bridges are already possible (var 41). I wonder that non implements it
20:23:08  <frosch123> planetmaker: i somehow think you are just looking at a not-implemented site :)
20:23:31  <planetmaker> hm, are the bridges not as implemented as described in the newgrf wiki?
20:23:57  <planetmaker>
20:24:16  <frosch123> that page is a draft of a wip of eis_os
20:24:32  <frosch123> there is no action123 implementation for bridges
20:24:39  <frosch123> well - no released one
20:26:15  <FooBar> can't you do snowy bridge overlays with the tile type check from railtypes?
20:26:26  <frosch123> hmm, though that varaction2 is actually implemented in ttdp, but iirc no action3
20:26:40  <Ammler> FooBar: ser does that already, afaik
20:26:41  <frosch123> FooBar: swedish rails does so
20:26:56  <FooBar> ok, never mind then ;)
20:27:48  <FooBar> actually, I do that myself with metrotracks as well... Just forgot that I did I suppose :P
20:27:51  <Ammler> but most missing feature is road crossing overlay, isn't? :-)
20:29:22  <Ammler> are raod crossings part of raod or rail?
20:29:30  <FooBar> rail
20:29:43  <FooBar> at least, with railtypes
20:30:06  <Ammler> then there is a overlay for it already?
20:30:09  <FooBar> sure
20:30:26  <Ammler> hmm, then pm fooled me :-P
20:30:41  <planetmaker> :-)
20:30:41  <FooBar> type 07 for action 3 for railtypes
20:31:15  <planetmaker> Ammler: how else should I have gotten snowy tracks on bridges?
20:31:18  <Ammler> so pm we (you) can go for default rail set :-P
20:31:42  <Ammler> pm, we spoke about road crossing
20:31:52  <Ammler> (or I)
20:31:59  <FooBar> me too ;)
20:32:02  <planetmaker> But those sprites are the foundations sprites which _must overpaint_ the existing tracks
20:32:31  <Ammler> you can't use "blank" road tiles?
20:32:42  <planetmaker> ?
20:32:58  <planetmaker> rail types don't care about roads
20:33:12  <Ammler> [22:30] <FooBar> type 07 for action 3 for railtypes <-- what's that then?
20:33:22  <planetmaker> tracks on bridges
20:33:23  <FooBar> Ammler: level crossings
20:33:28  <planetmaker> oh, or that
20:33:35  <Ammler> :-P
20:33:36  <planetmaker> but railtypes doesn't provide road sprites
20:33:41  <Ammler> no need
20:33:45  <FooBar> at least that's what Ammler and I was talking about ;)
20:33:46  <Ammler> that is thw whole point
20:33:47  <planetmaker> exactly
20:33:49  <planetmaker> :-)
20:34:01  <Ammler> but you can make full road crossing support
20:34:05  <planetmaker> Yes
20:34:06  <Ammler> I thought that isn't possible
20:34:12  <planetmaker> That's the point of railtypes
20:34:31  <FooBar> but indeed bridges is something that needs some work
20:34:39  <Ammler> so then tell me again, what is the issue, when we make a default rail type newgrf?
20:34:46  <Ammler> and a "empty" bridge set
20:35:30  <planetmaker> that it's not a static newgrf
20:35:42  <Ammler> why does it need to be static?
20:35:46  <planetmaker> making it in a newgrf which is not ogfxe_extra is very fine
20:36:05  <planetmaker> Ammler: because sprite replacements then have no effect anymore
20:36:22  <planetmaker> it disables all old-style newgrfs effectively which replace tracks
20:36:42  <Ammler> we make a ActionA newgrf to "clean" the default bridges
20:36:50  <planetmaker> hm?
20:37:08  <planetmaker> Well: I'm all for making such newgrf which implements the four defaults as railtypes
20:37:13  <planetmaker> OpenGFX+ can include that all
20:37:32  <planetmaker> Then we can after that add bridges there, too
20:37:42  <planetmaker> Are you comfortable to help with that? :-)
20:37:56  <Ammler> well, we need someone to clean the bridge sprites
20:38:28  <Ammler> might be more fun than coding the signals :-P
20:39:04  <FooBar> only 45-ish sprites, so I guess about 30 minutes work
20:39:21  <planetmaker> yeah. Cleaning the bridge sprites can be moderately done.
20:39:40  <planetmaker> I guess I could strip-down se rails to a very basic railtypes newgrf and add it to ogfx+
20:39:55  * planetmaker wonders though... ogfx+ will become a really strange assortment of newgrfs...
20:39:58  <Ammler> I am not sure, if ogfx+ is good for that
20:40:08  <planetmaker> whether it would not be better to keep different things separate
20:40:20  <Ammler> yes :-)
20:40:27  <planetmaker> Like... I once proposed to include the climatespecific airports there. But I'm not sure anymore. Why should one?
20:40:56  <FooBar> shoudn't those just be in _extra?
20:40:59  <planetmaker> Though... they can be static as they're now. That could even be in ogfxextra maybe... hm
20:41:01  <planetmaker> :-)
20:41:28  <frosch123> in ogfx+ you can do snow-aware airports
20:41:30  <FooBar> oh, I'm missing an l in shoudn't... oh well :P
20:42:29  <planetmaker> frosch123: the airportsplus from Yexo: can they be static?
20:42:29  <frosch123> oh, and rotateable airports are also already possible
20:42:41  <frosch123> no, newairports are not static
20:42:42  <planetmaker> those which just use better ground tiles?
20:42:57  <frosch123> they reserve airportstiles
20:43:08  <frosch123> they have animation stages and so on
20:43:10  <planetmaker> ok. So... then it should stay an airport newgrf
20:43:14  <frosch123> immediate desync :)
20:43:14  <Yexo> they're not simple graphic replacements, although they do look like it
20:43:31  <Ammler> but maybe we could use it
20:43:37  <planetmaker> But it really starts to make sense to pimp them more :-)
20:43:49  <Ammler> I mean the sprites
20:46:08  <planetmaker> hm... maybe I should make ogfx+ not one newgrf but several. Possibly in one project, but several newgrf :-)
20:46:17  <planetmaker> _that_ sounds like a plan :-)
20:46:55  <planetmaker> what do you guys think of that?
20:47:22  <Yexo> sounds good
20:47:25  <planetmaker> Having these simple? enhancement newgrfs for different features in that one repo, but several newgrfs?
20:47:58  <planetmaker> Because I really started to worry with industries, vehicles, airports, railtypes... it would become a mess :-)
20:48:01  <Yexo> I guess the alternative is one big newgrf with a lot of parameters to disable all features
20:48:22  <planetmaker> yeah. And... then we'd be quak'ed at that monolithic newgrfs are bad.
20:48:25  <planetmaker> For good reason
20:48:48  <frosch123> :)
20:48:49  <FooBar> I'd go for the parameter option, as with the action 14 that is much more user-friendly than downloading and activating umphteen grfs...
20:49:22  <planetmaker> FooBar: base grf and others reading that?
20:49:37  <FooBar> we were talking ogfx+ weren't we?
20:49:41  <planetmaker> yes
20:49:50  <planetmaker> 'base' as in 'gets the parameters'
20:49:56  <FooBar> oh ok :)
20:50:02  <FooBar> no, I meant just one big thing
20:50:03  <planetmaker> but... I like smaller on-purpose better
20:50:24  <FooBar> I guess both have advantages and disadvantages
20:50:44  <planetmaker> base costs handling is an advantage for on-purpose
20:50:45  <FooBar> let me try more disadvantages :P
20:51:11  <FooBar> you need to upload more than one grf to bananas instead of just one
20:51:24  <planetmaker> yes
20:51:41  <FooBar> can the makefile make more than one grf at this point?
20:51:45  <planetmaker> yes
20:51:56  <planetmaker> opengfx is exactly this makefile
20:51:56  <FooBar> ok, so then you need not change that :)
20:52:01  <Yexo> that is also an advantage: you can update one part (railtypes) without influencing games that only use the vehicle parts
20:52:56  <planetmaker> OGFX+ rails, OGFX+ vehicles, OGFX+ airports, OGFX+ bridges
20:53:12  <FooBar> that's not possible if the railtype part is guarded with a parameter in the vehicle-only game?
20:53:15  <planetmaker> OGFX+ industries
20:53:30  <planetmaker> how do you mean, FooBar ?
20:53:36  <FooBar> what yexo said
20:53:50  <planetmaker> ah. No, then it's replacing an existing newgrf
20:54:36  <Ammler> planetmaker: one repo per newgrf
20:54:44  <Ammler> but just make it subprojects
20:55:10  <planetmaker> Hm... why not one repo?
20:55:22  <Yexo> FooBar: you'd have to replace the old newgrf with the newer version, while that is technically possible you'd have to copy the parameters manually, if you accidentally do anything wrong the game can break
20:55:45  <Ammler> how will you manage building different newgrfs?
20:55:53  <planetmaker> I'd always build all
20:56:28  <FooBar> Yexo: if you delete old grf and openttd finds new grf and loads that as "compatible", it will not keep parameter?
20:56:37  <Yexo> FooBar: yes, it will
20:56:42  <FooBar> it's a different story if the grfid changes though...
20:56:48  <Yexo> but with the content download a lot of users won't know how to delete the old grf
20:57:17  <planetmaker> well. action14 should tell ;-)
20:57:18  * FooBar votes for an ingame option to delete old downloaded content
20:57:27  <FooBar> but then as this is a democracy and most people are in favour of multiple grfs, I better shut up now ;)
20:57:47  <planetmaker> Well, nothing is done yet.
20:57:55  <FooBar> on a different note, what would OGFX+ industries include if there is FIRS? :P
20:58:12  <Ammler> FIRS light :-P
20:58:25  <planetmaker> Just three trams, some slightly modded industries, some train mods, a heli mod
20:58:35  <planetmaker> FooBar: you'd overwrite it again
20:58:50  <planetmaker> You re-define the industries anyway, do you?
20:59:31  <FooBar> to be honest, I don't know what we do...
20:59:51  <FooBar> I don't think we disabled all default industries before redefining new ones
20:59:52  <Ammler> planetmaker: using one repo for differnet newgrfs does only make sense if you share something, will you?
21:00:19  <Ammler> I mean, I just found out that my MiniGRFs repo is stupid :-)
21:00:23  <Yexo> FooBar: if firs "overrides" an old industry than that industry is automatically disabled and replaced by your industry
21:01:20  <FooBar> well yes, but we don't override every possible industry ID
21:02:04  <Yexo> oh? I thought firs redefined all industries
21:02:11  <Yexo> or are some of the original industries still used?
21:02:55  <FooBar> I had a look and we disable all industies to 24h
21:03:01  <FooBar> that is all default industries
21:03:12  <planetmaker> FooBar: then it's no problem.
21:03:28  <planetmaker> OpenGFX+ only allows banks, water towers and power plants to also close down
21:03:29  <FooBar> I don't think so either now that I checked :P
21:04:37  <Ammler> pm, ogfx+ isn't static so merging with the clima airport grf isn't that stupid
21:04:55  <planetmaker> Ammler: in the currently discussed form: yes, I agree
21:05:09  <planetmaker> Then the airports of yexo would become the opengfx+ airports
21:05:46  <planetmaker> but they'd remain their own newgrf anyway. Just re-written in NML ;-)
21:05:54  <Yexo> planetmaker: that means that when someone uses opengfx+ industries in combination with firs you'd have 2 banks, 2 water towers and 2 power plants
21:06:13  <planetmaker> Yexo: would it?
21:06:20  <FooBar> FIRS doesn't have banks or power plants ;)
21:06:23  <planetmaker> The IDs would be re-defined, wouldn't they?
21:06:42  <Ammler> Yexo: if you are right, there is no limit for industries?
21:06:49  <planetmaker> in any case, that's one of the reasons to not use it ;-)
21:06:50  <FooBar> limit is 64
21:06:58  <planetmaker> not use it in that case
21:07:00  <Ammler> how is that limit made?
21:07:10  <planetmaker> writing 6 and then writing 4
21:07:12  <planetmaker> :-P
21:07:14  <Yexo> the openttd internal industry ids 0 to 24 (or 23?) are always the original industries, they can be disabled (either by setting their override to FF or by overriding them) and newgrf industries can be added
21:07:40  <Ammler> but ogfx+ does override the default bank
21:07:44  <Yexo> if you have a a newgrf that changes any part of an industry it gets a new internal id (24+) and all properties from the original industry are copied
21:07:48  <planetmaker> Yexo: but... do I override it, if I just modify an action0 for it?
21:07:49  <Ammler> and firs, if they would have banks, would do the same
21:07:52  <planetmaker> I guess
21:08:42  <Yexo> planetmaker: action0 industries prop 08 means "create a new internal id for this industry, copy all properties from the substitute type"
21:08:54  <Yexo> actually not really in that order, but that's the basic idea
21:09:05  <planetmaker> ok yeah. wrote at the same time you wrote it :-)
21:09:13  <Ammler> you just do 08 <id> 09 <id>
21:09:19  <Ammler> and it is overriden
21:09:46  <Yexo> 09 <id> just sets a property <overriden-by> for the old industry type (if it wasn't set already by another newgrf)
21:09:55  <Yexo> and it also disables the old industry at the same time
21:10:19  <Ammler> if you wouldn't use 09, you would have 2
21:10:29  <Yexo> Ammler: you always have 2 internal ids (in openttd)
21:10:54  <Yexo> The non-overridden original types count towards this limit. <- from the wiki, that isn't true, the original types always count towards the limit in openttd, even if they're overridden
21:11:39  <Ammler> so even if I use 09, I will have another id?
21:12:16  <Yexo> in openttd yes
21:12:32  <planetmaker>
21:12:35  <Yexo> in ttdpatch probably not, given the documentation I quoted above
21:13:20  <Brot6> OpenGFX+ - Support #1253 (New): Re-structuring of OpenGFX+ (planetmaker) @
21:15:50  <frosch123> Yexo: that sentence also holds for ottd
21:16:04  <frosch123> industries are different from industry tiles and houses
21:16:14  <Yexo> they are? hmm
21:16:23  * Yexo looks at the industry code again
21:17:05  <Ammler> well, it should be, exactly to "prevent" having same industry multiple times, if there is such a low limit
21:18:03  <Ammler> FooBar: andythenorth, what happen with the idea to have industries changing with time?
21:18:23  <FooBar> the idea is still there, it just lacks implementing ;)
21:18:45  <FooBar> it can only be tested well if all industries are implemented
21:19:09  <frosch123> Ammler: industries too slow appearing once they are available
21:19:37  <planetmaker> the main problem is that the tiles can't be re-defined, I guess.
21:19:52  <planetmaker> Though, they probably could change their appearance via animation in time
21:20:00  <Ammler> is there also a tiles limit?
21:20:25  <Ammler> (I mean low limit)
21:20:41  <Yexo> frosch123: thanks, they indeed work different
21:21:46  <Yexo> Ammler: no
21:21:58  <Yexo> 512 total industry tiles, but that includes the original tiles
21:22:05  <Yexo> for ttdpatch it's 256 tiles not including original tiles
21:22:14  <Ammler> well, that is low, isn't?
21:22:21  <Yexo> it isn't
21:22:26  <Yexo> each grf can only define 256 tiles anyway
21:22:31  <planetmaker> @calc 9*64
21:22:31  <Webster> planetmaker: 576
21:22:44  <FooBar> you need only 1 to 3 tiles per industry, so that's not a real problem
21:22:45  <Yexo> normally 2 or 3 tileids per industry should be enough
21:22:54  <FooBar> :)
21:22:55  <planetmaker> oh, so no 64 industries with each 9 different tiles ;-)
21:23:51  <Yexo> each tileid can look different depending on a varaction2 chain, for example depending on the location of the tile
21:24:18  <planetmaker> what does one need different tiles for then?
21:24:29  <planetmaker> just to keep the varaction2 chains short(er)?
21:24:38  <FooBar> only 50 different tiles in FIRS
21:24:50  <FooBar> and currently 38 industries
21:24:59  <planetmaker> :-)
21:25:06  <frosch123> planetmaker: there are some propeties which cannot be changed via callbacks
21:25:20  <planetmaker> ah... yes...
21:25:59  <Yexo> are there actually any for industry tiles?
21:26:13  <andythenorth> evening
21:26:21  <FooBar> 'night
21:26:21  <andythenorth> what are we changing?
21:26:25  <andythenorth> :)
21:26:27  <FooBar> tiles
21:27:07  <andythenorth> what's wrong with them? :)
21:27:36  <FooBar> nothing really ;)
21:27:44  <planetmaker> uh oh. brb. Bouncer rebooting
21:28:03  <FooBar> it's just what we were talking about until you entered :)
21:28:26  <FooBar> I don't think industries can change their cargo acceptance over time, can they?
21:28:44  <planetmaker> they shouldn't ;-)
21:29:35  <Yexo> industry have 3 cargo acceptance slots, they can temporarily disable each one (disable slot 1 from 0 to 196o and slot 1 from 1960 to ...)
21:29:51  *** XeryusTC has quit IRC
21:29:51  *** SmatZ has quit IRC
21:29:51  *** tneo has quit IRC
21:29:51  *** planetmaker has quit IRC
21:29:56  <Yexo> but I don't think they can change the cargo used in a certain slot (they can with a callbcak that is run when the industry is build, but not later on)
21:30:06  <andythenorth> I've thought about it before
21:30:13  <FooBar> that's what I read as well...
21:30:25  <frosch123> Yexo: iirc tiles can change acceptance, but not the cargo processed by the industry
21:30:49  <frosch123> but maybe i mix it up with houses :)
21:30:57  <Yexo> no, that's exactly what I thought :)
21:31:01  <andythenorth> cargos is an action 0 thing
21:31:13  <andythenorth> there is a cb to change it on construction, that's it though
21:31:52  <frosch123> FooBar: iirc ecs powerplant starts to accept oil somewhen
21:32:08  <frosch123> maybe also pbi?
21:32:14  <andythenorth> not pbi
21:32:23  *** ODM has quit IRC
21:32:23  <andythenorth> I'm planning some limited use of acceptance changes
21:32:34  *** Seberoth has joined #openttdcoop.devzone
21:32:40  <andythenorth> e.g. FIRS markets stop accepting milk after a certain date
21:33:11  <frosch123> hmm, where do you deilver milk to then?
21:33:14  <andythenorth> Dairy
21:34:04  <andythenorth> I've avoided this sort of thing so far because (a) might be bad for gameplay
21:34:12  <Yexo> andythenorth: AIs don't like those kind of changes
21:34:19  <andythenorth> (b) I can't control the text showing what cargos the industry requires / will process
21:34:59  <andythenorth> Yexo: fair point
21:35:09  <frosch123> you can display a text after the cargo
21:35:16  <frosch123> like "currently not accepted"
21:35:23  <andythenorth> frosch123: still confusing though, no?
21:35:38  <andythenorth> 'only after 1890' ??
21:35:40  <FooBar> Accepts: Milk (currently not accepted) ;)
21:35:53  *** pm has joined #openttdcoop.devzone
21:36:09  <frosch123> "after invention of electricity" ?
21:36:14  <frosch123> :p
21:36:21  <FooBar> Maybe we should just stick with changing some graphics over time to 'modernize' industries
21:36:28  <FooBar> but that's something for 1.1
21:36:30  *** pm is now known as Guest652
21:36:38  <andythenorth> FooBar: 0.9 :P
21:37:08  <FooBar> whatever you want; I fear you have to draw most of it anyways ;)
21:37:15  <Rubidium> 0.10!
21:37:27  <Rubidium> (best of both worlds)
21:37:29  <frosch123> firs is written in nfo, so 0.A
21:37:35  <FooBar> :)
21:37:40  <andythenorth> also if acceptance changes, I would want to broadcast a message (once) to players.  There's no easy way to do that.
21:37:57  <FooBar> I actually number my readmes like that, with section A after section 9
21:38:01  <andythenorth> so generally fooling with acceptance doesn't look too attractive
21:38:37  <FooBar> adding an accepted cargo type is fine, but opting-out is a bit tricky
21:38:51  <andythenorth> if there was some kind of scenario / goals framework....might be a different story :o
21:39:09  <andythenorth> could script all kinds of fun changes :)
21:40:01  <FooBar> I think we best stick to closing some historic industries after opening a different modern industry
21:40:10  <andythenorth> the best suggestion I've seen is to encourage players to ship to newer industries is to have them be better than the older types
21:40:18  <FooBar> that though needs checking if the modern industry actually exists
21:40:25  <andythenorth> that can be done
21:40:40  <andythenorth> lower production ratios ('ineffeciency') might work best for gameplay
21:40:49  <andythenorth> though for 'milk' that would be rather stupid :)
21:41:37  <andythenorth> hmm
21:41:43  <andythenorth> [forum questions]
21:41:50  <FooBar> lowering production ratios after introduction of modern industry could work; players will move to modern industry; old industry will close itself after a while without delivery
21:42:08  <Guest652> the general problem is the timeline.
21:42:12  <andythenorth> brings me neatly to my next question...does *anyone* actually know how FIRS closure works?
21:42:16  * andythenorth doesn't
21:42:35  <Guest652> There may be years attached to it, but... they're at least for me basically meaningless and unconnected to the real world
21:42:36  <FooBar> I though that was your area
21:42:47  <andythenorth> FooBar: well I did write that code :)
21:42:51  <Guest652> Building the transport company goes by a completely different time
21:43:29  * andythenorth looks at industry_closure_check.pnfo
21:43:33  <Guest652> so I'd not put too much emphasis on time line and especially elaborate changes therein
21:43:49  <FooBar> planetmaker: not a lot of industries will feature this "replacement by modern new industry"
21:44:08  <Guest652> I guess it's one reason I made the old->modern transition for SE rails a parameter :-)
21:44:10  <FooBar> blacksmith and guano mine are the ones I can think of now
21:44:54  <Guest652> yeah, that makes sense :-)
21:45:00  <Guest652> still :-)
21:45:09  <Guest652> industries_never_expire ;-)
21:45:18  <Guest652> boolean yes/no ;-)
21:45:31  * andythenorth reads code
21:45:33  <FooBar> yes, it can be a parameter
21:45:59  <andythenorth> seems that FIRS checks for cargo produced.  If no cargo produced for n months, then random chance of closure
21:46:07  * FooBar wonders how the guano mine actually should be drawn...
21:46:08  <andythenorth> dunno if it works in game, testing it got boring :P
21:46:35  <FooBar> you have to test it while testing something like, say, URKS2
21:46:48  <FooBar> i mean UKRS :$
21:47:08  <andythenorth> I'm not testing UKRS2 until I have a worthwhile FIRS release candidate to test with :)
21:47:23  <andythenorth> needs industry chains complete in 1830 for starters :P
21:47:32  <FooBar> I started on that :)
21:47:37  <andythenorth> and some way of having a steel mill get built by about 1900.
21:47:52  <andythenorth> 'opening' industries is a nice idea, but currently fails on the fact that they don't
21:47:53  <andythenorth> (open)
21:48:55  <andythenorth> I should make enough money to build my own, but I can't with UKRS2 and horses, no ships
21:49:05  <FooBar> maybe do something with CB22?
21:49:31  <FooBar> like "if after 1900 and no steel mill available, all other industries cannot be built"
21:49:42  <andythenorth> interesting suggestion
21:50:12  <andythenorth> might work...couple of problems though...
21:50:15  <FooBar> that should come with OpenTTD actually trying to build a different industry if the first type it chose is not available...
21:50:23  *** SmatZ has joined #openttdcoop.devzone
21:50:34  *** Guest654 has joined #openttdcoop.devzone
21:50:35  <andythenorth> all industries would have to check a (quite long) list of other industries
21:50:45  *** tneo has joined #openttdcoop.devzone
21:51:10  <Guest654> ah :-)
21:51:20  <andythenorth> could be done
21:51:24  <FooBar> Or we just need a new callback to temporarily increase chance of construction :P
21:51:37  <andythenorth> that is also a nice suggestion
21:52:00  *** Guest654 is now known as planetmaker
21:52:02  <andythenorth> hacking cb22 might actually work.  Sometimes the 'wrong' route works with less effort than the 'right' route
21:53:33  <andythenorth> meanwhile....guano mine should be a 2x2 tile industry at sea
21:53:44  <andythenorth> or alternatively, it could be a drift mine into a hill
21:53:55  <FooBar> I understand guano mines are usually caves
21:54:31  <andythenorth> also sea rocks / cliffs
21:54:49  <Yexo> <FooBar> that should come with OpenTTD actually trying to build a different industry if the first type it chose is not available... <- openttd choses a random industry from all available industries, if you make all but one industry type unavailable it'll always chose that industry type
21:55:15  <FooBar> neat, so that CB22 stuff should actually work :)
21:55:29  <andythenorth> it's a good suggestion
21:55:47  <Yexo> I'm not sure the "number of steelmills on the map" information is actually available
21:55:52  <andythenorth> it is
21:56:05  <andythenorth> I thought it was relatively expensive to get though
21:56:10  *** Guest652 has quit IRC
21:56:31  <Yexo> that doesn't matter, the callback is only called once per industry type and only every few days (depends on map size)
21:56:40  <andythenorth> every industry available will have to check up to 63 other industry types...
21:57:30  <andythenorth> how we store the dates might become an interesting bit of cpp design
21:57:46  <planetmaker> :-) just a list of defines
21:57:52  *** planetmaker has quit IRC
21:57:52  *** tneo has quit IRC
21:57:52  *** SmatZ has quit IRC
21:58:01  <FooBar> "Distance of nearest industry with given type"
21:58:52  <andythenorth> var 67 is most effective for this
21:58:52  <FooBar> so every other industry checks distance towards steel mill, if return is FFFFFFFF, industry is unavailable
21:59:01  *** planetmaker has joined #openttdcoop.devzone
21:59:18  *** planetmaker has quit IRC
21:59:19  <FooBar> if I understand correctly, you don't need to check for every industry type
21:59:21  <Yexo> no variable from is available during cb 22
21:59:28  <Yexo> at least if I read the code correctly
21:59:37  <andythenorth> there's always something blocking the nice hack :)
22:00:00  <andythenorth> FooBar: we'd need to check for other industries with intro date.  But not 63 types I guess
22:00:01  *** SmatZ has joined #openttdcoop.devzone
22:01:26  <FooBar> darn
22:01:43  <andythenorth> even if it works, there's an unintended consequence where nothing gets built
22:01:55  <andythenorth> due to first industry in list not being buildable
22:02:05  <andythenorth> it would be better handled by the game
22:02:19  <Yexo> <andythenorth> due to first industry in list not being buildable <- why would that happen?
22:02:23  *** tneo has joined #openttdcoop.devzone
22:02:46  <frosch123> variables for cb22 would need special handling. the industry has no map location in that case...
22:02:54  <andythenorth> lets say there's an industry which can't be placed as it doesn't fit
22:02:56  *** SmatZ has quit IRC
22:02:56  *** tneo has quit IRC
22:03:10  <andythenorth> so every time cb22 runs, there's no instance of it, so all other industries disable themselves.
22:03:15  <andythenorth> so no industries get built
22:03:36  <Yexo> that can happen, but in case that one industry can't be build anywhere how likely is it that other industries can be build?
22:03:53  <andythenorth> in the case of something like the aluminium plant, which is large, fairly likely
22:04:06  <andythenorth> mountainous map, small map, lots of water on the map
22:04:08  <Yexo> hmm, true
22:04:11  *** planetma- has joined #openttdcoop.devzone
22:04:14  <andythenorth> some maps won't build sand pits for example
22:04:29  * andythenorth beer
22:04:42  *** frosch123 has quit IRC
22:04:43  <Yexo> all other industries could disable themself 9/10 times if one industry type is not yet on the map
22:05:02  *** planetma- is now known as planetmaker
22:05:05  <Yexo> that way every time cb22 is run some random portion of the industries is always available
22:05:20  <FooBar> hmmm "If the random game probability value is nonzero, at least one instance of this type is guaranteed to appear on the map."
22:05:25  <Yexo> you don't _force_ the building of the non-existend industry type, but you do make it far more likely without completely disabling other industry types
22:06:03  *** tneo has joined #openttdcoop.devzone
22:06:20  <andythenorth> FooBar: that documentation is empirically wrong
22:06:22  <andythenorth> :)
22:06:31  <FooBar> I figured :)
22:06:54  <andythenorth> Yexo: how would the other industries stay in sync to do that?
22:07:01  <andythenorth> check for an 'r' in the month?
22:07:02  *** SmatZ- has joined #openttdcoop.devzone
22:07:03  <andythenorth> :P
22:07:25  <andythenorth> "It's March, make building possible"...
22:07:59  <FooBar> different suggestion: at 1900/1/1 all other industries opt-out of being available for two years and then just hope the steel mill will be built some day...
22:08:07  <Yexo> (days since 0 % industry_id) < 6 -> make building possible
22:08:27  <andythenorth> storage in each industry?  That would work
22:08:43  <andythenorth> I was trying to make an argument for grf-local storage :P
22:09:35  <andythenorth> what happens if an industry-airport tries to close?  Does it have to wait for all vehicles to clear the state machine?
22:09:52  <FooBar> I'm in favour of a new feature that allows CB22 to access industry-specific variables, as I don't see why it shouldn't be able to
22:09:54  <planetmaker> good nicht
22:10:05  <Yexo> night planetmaker
22:10:08  <andythenorth> bye planetmaker
22:10:09  <FooBar> gute nacht
22:10:10  <Yexo> andythenorth: no idea yet
22:10:22  <andythenorth> Yexo: I think the answer has to be yes
22:10:39  <andythenorth> if you shut the industry with vehicles in it / on it....bad stuff happens
22:10:42  <Yexo> the problem is that vehicles don't necesarily leave the statemachine
22:10:56  <Yexo> the statemachine could be bugged for example
22:11:00  <Yexo> same with normal airports of course
22:11:09  <andythenorth> or they could be waiting for full load that never comes
22:11:12  <FooBar> also if vehicles are stopped in depot...
22:11:18  <Yexo> and what about "full load" orders when the industry stops producing because it wants to close?
22:11:23  <andythenorth> so industry closure could thus be prevented
22:11:27  <andythenorth> interesting hack
22:11:45  <Yexo> I guess in such cases there need to be some "force vehicle to leave statemachine" code in openttd
22:12:59  <FooBar> maybe crash the vehicles :D
22:13:38  <andythenorth> vehicles stopped in depot are a poser :)
22:13:39  <Yexo> "the hangar burned down to the ground. All aircraft inside were lost"
22:13:58  <andythenorth> "vehicles were impounded and scrapped"
22:14:21  <andythenorth> the game has been getting too nice anyway, with disasters off, breakdowns off, PBS...
22:15:36  <andythenorth> FooBar: the best thing for industry might be frosch's suggestion to make probability a cb.
22:15:42  <andythenorth> it's the cleanest route
22:15:46  <FooBar> true
22:16:07  <andythenorth> cb 22 basically returns a probability already
22:16:14  <andythenorth> so adapting it might be the best
22:16:26  <andythenorth> current probability is 0 or 1 :P
22:16:58  *** planetmaker has quit IRC
22:16:58  *** tneo has quit IRC
22:16:58  *** SmatZ- has quit IRC
22:17:34  <FooBar> or just the new callback that allows changing industry random probability value
22:18:06  <FooBar> but I guess it's good night for me as well :)
22:18:12  <FooBar> bye!
22:18:41  <andythenorth> me too
22:18:43  <andythenorth> good night
22:18:54  *** FooBar has quit IRC
22:20:18  *** tneo has joined #openttdcoop.devzone
22:20:49  *** SmatZ- has joined #openttdcoop.devzone
22:44:23  <Brot6> Autopilot - Revision 76:55c22a70e0de: (svn r787) Extend config with keys for custom commands and ... (Ammler) @

Powered by YARRSTE version: svn-trunk