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> svn.openttdcoop.org that is 11:41:04 <Brot6> Autopilot - Feature #1251 (Assigned): convert to hg (Ammler) @ http://dev.openttdcoop.org/issues/1251 11:41:04 <Brot6> Autopilot - Feature #1252 (New): integrate the custom commands (Ammler) @ http://dev.openttdcoop.org/issues/1252 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) @ http://dev.openttdcoop.org/issues/280#change-3175 12:36:28 <Brot6> OpenGFX - Bug #280: standard signals (Ammler) @ http://dev.openttdcoop.org/issues/280#change-3176 12:41:43 <Brot6> OpenGFX - Bug #280: standard signals (2006TTD) @ http://dev.openttdcoop.org/issues/280#change-3177 12:42:55 <Brot6> OpenGFX - Bug #280: standard signals (Ammler) @ http://dev.openttdcoop.org/issues/280#change-3178 12:44:29 <Brot6> OpenGFX - Bug #280: standard signals (Ammler) @ http://dev.openttdcoop.org/issues/280#change-3178 12:54:27 <Brot6> OpenGFX - Bug #280: standard signals (2006TTD) @ http://dev.openttdcoop.org/issues/280#change-3179 13:00:06 <Brot6> Unable to connect to http://dev.openttdcoop.org/sys/: Failed with 502 Bad Gateway 13:07:03 <Brot6> Unable to connect to http://dev.openttdcoop.org/sys/: 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 http://dev.openttdcoop.org/sys/: Failed with 502 Bad Gateway 13:21:02 <Brot6> Unable to connect to http://dev.openttdcoop.org/sys/: 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) @ http://dev.openttdcoop.org/issues/280#change-3180 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) @ http://dev.openttdcoop.org/projects/nutracks/repository/revisions/8afb91796072 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> www.link-to-a-hopper-and-with-stats.com ? :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 - http://bundles.openttdcoop.org/firs/nightlies/ERROR/r1190 16:18:36 <Brot6> newgrf_makefile: compile of r127 failed - http://bundles.openttdcoop.org/newgrf_makefile/nightlies/ERROR/r127 16:18:42 <Brot6> nutracks: compile of r93 failed - http://bundles.openttdcoop.org/nutracks/nightlies/ERROR/r93 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 - http://bundles.openttdcoop.org/2cctrainset/nightlies/ERROR/r580 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 - http://bundles.openttdcoop.org/nutracks/nightlies/ERROR/r93 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) - http://bundles.openttdcoop.org/firs/nightlies/r1190 16:48:34 <Brot6> newgrf_makefile: update from r124 to r127 done - http://bundles.openttdcoop.org/newgrf_makefile/nightlies/r127 16:49:17 <Brot6> nutracks: update from r92 to r93 done (13 errors) - http://bundles.openttdcoop.org/nutracks/nightlies/r93 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 - http://bundles.openttdcoop.org/2cctrainset/nightlies/ERROR/r580 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> http://dev.openttdcoop.org/projects/swedishrails/repository/entry/src/gfx/rails_overlays.png <-- 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) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/88bb608c8d5b 19:43:25 <Brot6> FIRS Industry Replacement Set - Revision 1192:1b30e83d756c: Feature: Blacksmith basic code and no... (foobar) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/1b30e83d756c 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) @ http://dev.openttdcoop.org/projects/32bpp-ez-patches/repository/revisions/cfd60f238883 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) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/46ba4a71faa7 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> http://wiki.ttdpatch.net/tiki-index.php?page=VarAction2Bridges 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> http://dev.openttdcoop.org/issues/1253 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) @ http://dev.openttdcoop.org/issues/1253 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 http://wiki.ttdpatch.net/tiki-index.php?page=VarAction2Industries 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) @ http://dev.openttdcoop.org/projects/autopilot/repository/revisions/55c22a70e0de