Config
Log for #openttdcoop.devzone on 17th August 2010:
Times are UTC Toggle Colours
00:21:16  *** KenjiE20 has quit IRC
01:50:47  *** Seberoth has quit IRC
05:21:53  *** Guest658 has joined #openttdcoop.devzone
05:22:14  *** Guest658 is now known as planetmaker
06:12:18  <Brot6> FIRS Industry Replacement Set - Feature #1254 (New): All snowline code should not assume Arctic c... (andythenorth) @ http://dev.openttdcoop.org/issues/1254
06:22:58  <Brot6> FIRS Industry Replacement Set - Feature #1254: All snowline code should not assume Arctic climate (planetmaker) @ http://dev.openttdcoop.org/issues/1254#change-3182
06:35:24  <Brot6> OpenGFX - Feature #839: 4737-4742: Fizzy drink factory (2006TTD) @ http://dev.openttdcoop.org/issues/839#change-3183
06:37:28  <Brot6> OpenGFX - Feature #1255 (New): Gumdrops (2006TTD) @ http://dev.openttdcoop.org/issues/1255
06:37:28  <Brot6> OpenGFX - Feature #839: 4737-4742: Fizzy drink factory (2006TTD) @ http://dev.openttdcoop.org/issues/839#change-3184
06:48:11  <Brot6> OpenGFX - Feature #1255: Gumdrops (planetmaker) @ http://dev.openttdcoop.org/issues/1255#change-3185
06:59:51  *** ODM has joined #openttdcoop.devzone
07:08:24  <Brot6> OpenGFX - Bug #683 (Closed): Blue eyes too blue (planetmaker) @ http://dev.openttdcoop.org/issues/683#change-3186
07:10:41  <Brot6> OpenGFX+ - Feature #957: forest (planetmaker) @ http://dev.openttdcoop.org/issues/957#change-3189
07:11:25  <Brot6> OpenGFX - Feature #662 (Resolved): Rework trains (planetmaker) @ http://dev.openttdcoop.org/issues/662#change-3191
07:14:07  <Brot6> OpenGFX+ - Feature #162 (New): OldGFX - GUI -> do we want that? (planetmaker) @ http://dev.openttdcoop.org/issues/162#change-3192
07:38:51  <ODM> opengfx and opengfx+? weird:P
07:40:26  *** frosch123 has joined #openttdcoop.devzone
07:56:09  <planetmaker> base set and extension :-)
07:56:31  <planetmaker> opengfx+ is unreleased, though
08:07:29  <Brot6> NFORenum - Revision 470:ca4cda99d996: Fix: support action2 objects variable 5F. (Rubidium) @ http://dev.openttdcoop.org/projects/nforenum/repository/revisions/ca4cda99d996
09:29:36  <Ammler> planetmaker: why can't you close #662?
09:31:47  <planetmaker> the trains? There's a dependency I missed
09:36:11  <Brot6> #openttdcoop NewGRF package - Support #1156 (Closed): Update homepages (Ammler) @ http://dev.openttdcoop.org/issues/1156#change-3196
09:40:42  <Brot6> OpenGFX - Feature #903 (Closed): grfcodec -c (was missing(?) sprites) (Ammler) @ http://dev.openttdcoop.org/issues/903#change-3197
09:42:26  *** Seberoth has joined #openttdcoop.devzone
09:49:56  *** SmatZ- is now known as SmatZ
10:24:00  *** KenjiE20 has joined #openttdcoop.devzone
10:41:35  <Brot6> OpenGFX - Feature #1255: Gumdrops (Ammler) @ http://dev.openttdcoop.org/issues/1255#change-3198
10:42:15  <Ammler> autsch
10:42:16  <Ammler> sorry pm
10:42:25  <Ammler> why did you move the temperate in toyland topic?
10:43:20  <Brot6> OpenGFX - Feature #156: Temperate sprites for toyland (Ammler) @ http://dev.openttdcoop.org/issues/156#change-3199
10:44:04  <Ammler> next time, I should first check, when the version was changed last time :-)
10:44:17  <Ammler> but you changed it without any reason
10:45:12  <Ammler> I don't think, you need to postpond tickets from 0.4, which is a later version anyway
10:45:35  <Ammler> I would make more sense to move tickets from 0.3.0 to 0.4
10:46:30  <planetmaker> uh... I moved temperate in toyland? You mean the version?
10:46:59  <planetmaker> I changed it to 1.0 as it's a HUGE task to replace all things with toyland only stuff
10:47:19  <planetmaker> Waiting and that only needs doing by the time we call it 'done'
10:48:01  <planetmaker> it won't be done by 0.3 nor by 0.4
10:48:17  <Ammler> well, we also might never reach 1.0 :-)
10:48:23  <planetmaker> we will.
10:48:26  <Ammler> :-P
10:48:55  <Rubidium> if you do it within 6 years from 0.1.0 you'll be even faster than OpenTTD :)
10:48:56  <planetmaker> And I changed it exactly for that reason: it won't be done before
10:49:10  <planetmaker> at least I don't *think* so
10:49:11  <Rubidium> OpenSFX on the other hand... that might never reach 1.0.0
10:49:17  <planetmaker> yeah... :S
10:50:03  <Ammler> maybe we can ask Arcon to fix http://dev.openttdcoop.org/issues/906, as he visited the thread right now
10:50:09  <planetmaker> Ammler, besides: target version is in my eyes a 'solve latest by'
10:50:43  <Ammler> for me it is just something we can change everytime we feel :-)
10:50:51  <planetmaker> which is pretty stupid
10:51:04  <planetmaker> then we don't need to set it at all when we constantly move it upwards
10:51:17  <Ammler> like if we now like to release 0.3.0, we can just move the pending tickets to 0.4
10:51:18  <planetmaker> and that's why I marked it 1.0
10:51:26  <planetmaker> which is stupid
10:51:31  <Ammler> true
10:51:39  <planetmaker> Then we should move all those things to 1.0 which we don't plan to do by 0.3
10:51:47  <planetmaker> Because they *have* to be done by 1.0.
10:51:55  <planetmaker> And *can* be resolved any release earlier
10:52:06  <Ammler> no, we can move that, when we like to release something but those aren't fixeable
10:52:10  <Ammler> like we did until now
10:52:21  <Ammler> but I see no reason to move things from 0.4
10:52:35  * Rubidium wonders why "we" never had such a debate :)
10:52:37  <Ammler> as that version isn't even started
10:52:40  <planetmaker> The target version is not a 'like to' but IMHO a 'must to'
10:52:58  <planetmaker> Ammler, then, there should be no version
10:53:04  <Ammler> Rubidium: because you have only _one_ manager :-)
10:53:08  <planetmaker> if it is a 'move to whenever desired'
10:53:57  <Rubidium> maybe it's because we don't give everything a due version :)
10:54:02  <planetmaker> ^
10:54:35  <Ammler> not giving a due version is the same like giving one but move around like the feeling
10:54:49  <planetmaker> but the latter is stupid
10:54:58  <planetmaker> creating useless spam
10:55:29  <Ammler> well, as said, I didn't check, that you just moved it
10:55:35  <Ammler> else I wouldn't have done it
10:55:42  <Rubidium> just declare 1 bug for 1.0.0: no more issues (implicitly depending on all other issues)
10:56:15  <Ammler> that is why I said "autsch" :-)
10:56:27  <planetmaker> Ammler, yes, I know :-)
10:56:35  <Ammler> that was to me :-P
10:56:57  <planetmaker> My argument was rather against  the incentive to mark issues as 'next' or '2nd next' release when there's no-one working on it and no end-of-task even visible
10:57:28  <Ammler> well, 2006TTD is obviously working on the fix temperate in toyland sprites
10:57:29  <planetmaker> especially that big tasks which will probably be there in another 12 months
10:57:41  <planetmaker> yes. But it's a BIG task
10:57:58  <planetmaker> he needs to re-do all stations / airports / bus stops / truck stops / docks
10:58:34  <planetmaker> Vehicles might need re-touch, too
10:58:54  <Ammler> target 1.0 is meant for stuff, which we even don't like to start, imo
10:59:14  <Ammler> but need to be done for it
11:00:00  <planetmaker> it's for all stuff which needs to be done but has no chance to be resolved by the next release
11:00:23  <planetmaker> Using 0.4 is completely useless ;-)
11:00:31  <Rubidium> ... unless someone puts really serious work into it
11:00:35  <Ammler> same with 1.0 :-P
11:00:38  <Ammler> in your view
11:00:58  <Ammler> 0.3 is next release, which is soon
11:01:04  <planetmaker> Ammler, no. 1.0 is the target revision when the bugs are fixed and all sprites there
11:01:16  <planetmaker> 1.0 is the vision
11:01:24  <Ammler> 0.4 is for things we are working but can't be finished to 0.3
11:01:27  <planetmaker> the minimum
11:01:34  <planetmaker> But no-one is working on the 0.4 things
11:01:36  <Ammler> 1.0 is for, yes we do, but we don't care
11:01:54  <Ammler> ...now
11:02:05  <planetmaker> *sigh*
11:02:13  <planetmaker> the point. So no-one knows when it will be done
11:02:46  <planetmaker> you know what: I delete 0.4 ;-)
11:02:56  <Ammler> then do the same with 1.0 :-P
11:03:18  <Ammler> I don't agree, but I also don't care ;-)
11:03:24  <Rubidium> suggestions: due date is when something *must* be done, i.e. roadmap-ish. If you don't think it'll make it put it in the "someone" state (i.e. 1.0)
11:03:45  <planetmaker> Rubidium, that's what I argue for. Yes.
11:03:50  <Ammler> really :-o
11:03:54  <Rubidium> if you don't feel it will be possible for 0.4, then don't say it should be done by 0.4. It'll only annoy users
11:04:00  <Rubidium> e.g. cargod*stt
11:04:07  <Rubidium> s/tt/t/
11:04:18  <Ammler> well, the roadmap is for us
11:04:40  <Ammler> it is a kind of measure, if we are ready for a release
11:04:52  <Ammler> it shouldn't be viewed as a "order"
11:04:54  <planetmaker> Ammler, we always have a measure for the next release
11:05:04  <planetmaker> and that's the important one
11:05:05  <Rubidium> whether your ready to release shouldn't depend on whether some features are implemented or not
11:05:26  <Ammler> yep, then we can simply move those tickets to the next version
11:05:36  <Rubidium> it should depend on things like open bugs (not feature requests)
11:05:49  <planetmaker> hm, yup
11:05:52  <Ammler> well, we have closed bugs, but we don't release
11:06:13  <Ammler> :'-(
11:06:13  <planetmaker> The question for some things, though, Rubidium is: there are 'features' which just are essential
11:06:28  <planetmaker> at least for 1.0
11:06:41  <Rubidium> as such feature requests have no due date, although you could add a pseudo due date for features that really need to be done for the 1.0
11:06:41  <planetmaker> But then... that's what we have the minor versions for, I guess
11:06:54  <Ammler> planetmaker: any example?
11:07:09  <planetmaker> Ammler, like the hay bales. They IMHO need to be done by 1.0
11:07:16  <planetmaker> But they're no bug
11:07:41  <Ammler> we have luck, that ogfx doesn't get new features
11:07:42  <planetmaker> Contrary the poor building stage for the bubble generator can be considered a bug. As such a show-stopper for 0.3
11:08:29  <Ammler> IMO, the missalignment of "my" houses could be a reason for a release
11:08:42  <planetmaker> yes
11:08:57  <planetmaker> But before we release there are some things we can still fix
11:09:05  <planetmaker> And those are the maglev track sprites (provided)
11:09:06  <Ammler> I am quite suprised about the few feedback about
11:09:08  <planetmaker> And the bubble generator
11:09:20  <planetmaker> I guess VERY FEW use the opengfx nightlies
11:09:30  <Ammler> no, that bug is in the release
11:09:36  <Ammler> that is why I would like one
11:09:42  <planetmaker> exactly. But you fixed it
11:10:02  <Ammler> it isn't that obvious there, because that didn't use -c
11:10:08  <planetmaker> Also, the Fizzy drink factory has new sprites. That can be in 0.3, too
11:10:21  <planetmaker> Same with signals. That's important
11:10:45  <planetmaker> ground tile toyland. That should not be a 0.3 show-stopper. So the 0.3 is out-of-place IMHO
11:10:58  <Ammler> yeah, signals I would like to make today, if nobody else does
11:10:59  <planetmaker> as there's concensus to not change it to the sprites provided
11:11:07  <planetmaker> Please do; I miss the time
11:11:44  <Ammler> I will template it like a combination of Acorn and 2006TTD
11:11:45  <planetmaker> I'm not sure how much the offcie building improvement is done #883
11:11:54  <planetmaker> 0.3 or not?
11:12:02  <planetmaker> If it's not done yet: then not 0.3
11:12:11  <Ammler> well, I should explain there what he did wrong
11:12:14  <planetmaker> same with fences on airports. There's little to do about it.
11:12:30  <planetmaker> Is it just that he didn't use the template as you like?
11:12:40  <planetmaker> Or what was that?
11:12:53  <Ammler> the house templates can quite well be used for flat tiles too
11:13:01  <planetmaker> yes. But you have the sprites
11:13:04  <Rubidium> anyhow, in my opinion, for each (major) release you should spend some work on fixing all bugs, i.e. put adding "features" on the back burner
11:13:16  <planetmaker> Rubidium, yes
11:13:32  <Ammler> Rubidium: there are 2 different bugs in ogfx
11:13:41  <Ammler> some we simply can't fix
11:13:55  <Rubidium> like?
11:14:00  <Ammler> graphics things
11:14:34  <Ammler> I can fix alingment bugs
11:14:51  <Rubidium> so you need some resident graphics guy in your team :)
11:15:00  <planetmaker> yes :-(
11:15:04  <Ammler> [13:14] <darix> Ammler: JFYI: the problems with the 11.2 and 11.1 "can not find key" should be fixed.
11:15:19  <Ammler> foobar was one
11:15:25  <Ammler> s/was/is/
11:15:38  <planetmaker> we should re-activate DanMacK :-)
11:15:51  <Ammler> on the other side, there aren't graphics bugs
11:15:56  <Ammler> only glithces
11:16:06  <planetmaker> which still needs a graphics artist
11:16:12  <planetmaker> there's no difference.
11:16:17  <Ammler> yes, but which don't stop a release
11:16:21  <planetmaker> Glitches just might need more patience than most devote
11:17:12  <planetmaker> http://dev.openttdcoop.org/issues/781 <-- and it's a bit frustrating when there's not really much quality feedback
11:17:20  <planetmaker> though I guess that issue can be closed...
11:24:06  <Ammler> yeah, that is a VERY silly thing
11:25:18  <planetmaker> what is veryy silly? That issue?
11:25:24  <planetmaker> Not really...
11:25:56  <Ammler> well, then answer my question :-P
11:26:39  <andythenorth> DanMacK is pretty busy with other stuff :)
11:27:12  <planetmaker> he's always pretty busy with other stuff
11:27:28  <planetmaker> despite he offered his drawing help
11:27:48  <planetmaker> Ammler, and you question is?
11:28:03  <Ammler> the last note there
11:28:30  <planetmaker> I've no idea
11:28:39  <planetmaker> Quality feed back would also involve an answer to that ;-)
11:29:05  <Ammler> yeah, but that makes it silly, imo, the bug not the lack of the feedback
11:29:49  <Ammler> well, the same is with my house realignment
11:30:06  <Ammler> as I made the bulk fix
11:30:30  <Ammler> I didn't respect odd bounding boxes
11:30:54  <Ammler> but it needed almost 4 months until someone reported it
11:32:06  <Ammler> before that, I would have made a bet, that the alignment is perfect :-(
11:38:14  <planetmaker> well. We cannot be perfect.
11:38:18  <planetmaker> We can only fix what we know
11:38:28  <planetmaker> It's the same here in OpenGFX like it is with OpenTTD
11:38:38  <planetmaker> People have to report bugs. We cannot see everything ourselves
11:41:26  <Brot6> Autopilot - Feature #1251 (Closed): convert to hg (Ammler) @ http://dev.openttdcoop.org/issues/1251
11:41:26  <Brot6> Autopilot - Feature #1251 (Closed): convert to hg (Ammler) @ http://dev.openttdcoop.org/issues/1251#change-3200
11:42:30  <Brot6> #openttdcoop - Support #144 (Closed): Tag will automatically create a release bundle (Ammler) @ http://dev.openttdcoop.org/issues/144#change-3201
11:42:30  <Brot6> #openttdcoop - Feature #182 (Rejected): Replace RSS Feed with hooks... (Ammler) @ http://dev.openttdcoop.org/issues/182#change-3202
11:53:54  <Ammler> Removed Category OpenGFX+ from OpenGFX
11:54:10  <Brot6> OpenGFX - Feature #595 (Closed): spin-off newgrfs (Ammler) @ http://dev.openttdcoop.org/issues/595#change-3203
11:58:23  <Brot6> OpenGFX - Feature #1200 (Feedback): NoGFX for dedicated (Ammler) @ http://dev.openttdcoop.org/issues/1200#change-3204
12:04:53  <Brot6> OpenGFX - Bug #1073 (Confirmed): medium font sprites too high (with accents) (Ammler) @ http://dev.openttdcoop.org/issues/1073#change-3205
12:07:43  <Brot6> OpenGFX - Feature #986: more snow sprites / smoother transition (Ammler) @ http://dev.openttdcoop.org/issues/986#change-3206
12:24:20  <Ammler> does railtypes btw. allow different signals?
12:29:56  <planetmaker> no
12:30:41  <Brot6> FIRS Industry Replacement Set - Bug #898: Bank appearing in Towns/Cities and accepting Sand (foobar) @ http://dev.openttdcoop.org/issues/898#change-3207
12:33:39  <Brot6> FIRS Industry Replacement Set - Feature #471: Blacksmith graphics (foobar) @ http://dev.openttdcoop.org/issues/471#change-3208
12:33:40  <Brot6> FIRS Industry Replacement Set - Bug #898: Bank appearing in Towns/Cities and accepting Sand (planetmaker) @ http://dev.openttdcoop.org/issues/898#change-3209
12:35:55  <Brot6> FIRS Industry Replacement Set - Feature #476: Windmill graphics (foobar) @ http://dev.openttdcoop.org/issues/476#change-3210
12:35:55  <Brot6> FIRS Industry Replacement Set - Feature #470 (Rejected): Vehicle Plant (foobar) @ http://dev.openttdcoop.org/issues/470#change-3212
12:36:46  <Brot6> FIRS Industry Replacement Set - Feature #472 (Rejected): Resort Hotel (foobar) @ http://dev.openttdcoop.org/issues/472#change-3213
12:37:35  *** FooBar has joined #openttdcoop.devzone
12:38:58  <Brot6> FIRS Industry Replacement Set - Feature #467 (Rejected): Fish Farm (foobar) @ http://dev.openttdcoop.org/issues/467#change-3214
12:42:41  <planetmaker> FooBar, you're fast resolving issues ;-)
12:42:52  <FooBar> I like those types of issues :)
12:42:57  <planetmaker> hehe
12:50:36  <Rubidium> do you have some method of donating to openttdcoop? So [hta]specx can put his positive issues somewhere as well? :)
12:51:25  <planetmaker> hm... I guess we should create a paypal account or so.
12:51:31  <planetmaker> we don't yet.
12:51:51  <planetmaker> Ammler, ^ or is there an easy to donate to account from the assoc?
12:52:17  <FooBar> probably the one who is actually paying for the server makes most sense to me for receiving the donations
12:52:42  <FooBar> otherwise you need to do even more bank transfers...
12:53:03  <planetmaker> that's either Ammler or me
12:53:46  <FooBar> well, either one of you two then :)
12:55:39  <FooBar> maybe also accept direct bank transfer; I believe that's free within Europe?
12:55:58  <FooBar> That way paypal doesn't get to keep the 4% they keep :)
12:56:15  <FooBar> I mean free within euro-countries
12:56:18  <Rubidium> FooBar: yeah... but only for EUR transfers
12:56:28  <FooBar> yes, that :)
12:57:24  <Rubidium> and you need all the info... IBAN and such, and that can be tricky to figure out... right, pm?
12:57:53  <planetmaker> oh yes :-)
12:57:56  <Rubidium> there's very little to find about the association itself though
12:58:09  <FooBar> last time I donated to orudge a reasonable amount got "lost in translation", both due to paypal commission and exchange rate; I didn't really like that
12:58:09  <Ammler> well, or we tell them, they sould donate some money to the homeless in the town or a church or something :-)
12:58:39  <planetmaker> woot, FooBar ?
12:58:50  <Ammler> I am also fine, if they donate to wwf or greenpeace
12:58:51  <planetmaker> Rubidium, yes, that's because the assoc is mostly dead
12:59:42  <Rubidium> Ammler: but donating to them is easy!
13:00:00  <Rubidium> they should donate to the Hiroshima peace fund (or whatever it's called these days)
13:00:50  <Ammler> planetmaker: wouldn't that be an idea, instead creating a donating page, we make a page and ask those people to donate to wwf or greenpeace in our name
13:01:16  <planetmaker> well... they could also donate to us ;-) And if we get too much we donate it for them ;-)
13:01:28  <planetmaker> or to orudge
13:01:42  <Ammler> orudge has already too much money
13:01:51  <planetmaker> has he?
13:02:01  <Ammler> well, as they said at the party
13:02:18  <planetmaker> Honestly, I don't mind, if people also donate to support the devzone...
13:02:32  <Ammler> me neither
13:02:47  <planetmaker> And if it's only so that I can donate more to... whatever, for example Welthungerhilfe like last Sunday
13:03:06  <Ammler> I prefer to help nature
13:03:16  <planetmaker> :-)
13:03:19  <Ammler> human help is something for the "big companies"
13:03:39  <planetmaker> See. Therefor it's good if people donate to the devzone. Then you can donate to nature, and I can donate to development aid ;-)
13:04:11  <planetmaker> (development aid is also natural protection work  ;-) )
13:04:24  <Ammler> IMO, it is stupid to buy cheap coffee and same time send money to that country so our dear Nestle can still make more money with cheap workers there
13:04:44  <planetmaker> that's not development aid ;-)
13:05:12  <Ammler> that is why I prefer sponsoring wwf and greenpeace :-)
13:05:14  <planetmaker> whatever. I think we indeed should start to supply a donation possibility
13:05:53  * planetmaker ponders 'private' or 'business' account with paypal
13:06:24  <Ammler> use "#openttdcoop association" if you need a name
13:06:30  <planetmaker> yeah
13:07:25  <Ammler> we should at least fake one meeting this year ;-)
13:07:32  <planetmaker> yep
13:07:52  <planetmaker> and change the constitution. To yearly or bi-yearly meetings
13:08:16  <KenjiE20> "I bring this meeting to order. Any items on the agenda? no? okay meeting adjurned" :p
13:08:33  <planetmaker> like that :-P
13:09:15  <Ammler> well, the assoc is reach, it has 100 CHF
13:09:22  <planetmaker> :-)
13:09:42  <planetmaker> which you all spent on booze! ;-)
13:09:56  <Ammler> which I then forgot
13:10:06  <Ammler> (to bring to the party)
13:11:15  <planetmaker> evil you!
13:11:19  * planetmaker hugs Ammler 
13:11:58  <Ammler> well, I pay the first 2 months with it
13:13:26  <Ammler> and we have again CHF60 in the current adsense
13:15:50  <planetmaker> since then?
13:37:19  <Brot6> FIRS Industry Replacement Set - Revision 1194:0aa0e07b197f: Feature: Wholesale Market basic code ... (foobar) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/0aa0e07b197f
13:39:48  <Brot6> FIRS Industry Replacement Set - Feature #462: Wholesale Market graphics (foobar) @ http://dev.openttdcoop.org/issues/462#change-3219
13:39:48  <Brot6> FIRS Industry Replacement Set - Feature #470: Vehicle Plant (andythenorth) @ http://dev.openttdcoop.org/issues/470#change-3220
13:40:36  <FooBar> andythenorth: then update your website so that it doesn't lead me to believe that you don't want it any more ;)
13:41:41  <andythenorth> FooBar: nah, that one's not deprecated :)
13:41:42  <andythenorth> http://tt-foundry.com/sets/FIRS/schema/industries?economy=everything#vehicle_plant
13:41:45  <Webster> Title: TT Foundry: Pixel Creations for OpenTTD (at tt-foundry.com)
13:42:00  <andythenorth> it would be good soon to talk about set / economy design
13:42:10  <andythenorth> I'd like to break the back of 0.4 first though
13:42:26  <andythenorth> It's going to be a big release, probably several hundred commits :)
13:42:27  * andythenorth afk
13:42:49  <FooBar> http://tt-foundry.com/sets/FIRS/schema/industries_coders doesn't agree...
13:42:51  <Webster> Title: TT Foundry: Pixel Creations for OpenTTD (at tt-foundry.com)
13:43:15  <andythenorth> FooBar: you're correct :o
13:44:08  <FooBar> but what is the advantage of the vehicle plant over the metal foundry?
13:44:18  <FooBar> metal foundry does the same, and more...
13:44:50  <FooBar> but I think most will just ship their steel to the machine shop...
13:47:22  <FooBar> also, I started adding the industry name to the top of it's pnfo file. Makes it easier to find where the industry starts if you have to read firs.nfo
13:47:33  <andythenorth> FooBar: good call
13:47:37  <FooBar> So if you could do the same as soon as you edit some industry...
13:47:48  <andythenorth> although really the make file should just insert it as a comment :)
13:48:07  <andythenorth> FooBar: I'm at work now, but can talk later
13:48:22  <FooBar> ok cool
13:48:23  <andythenorth> (advantage of vehicle plant comes if we add 'cars' as an economy specific cargo)
13:48:25  <andythenorth> cheers
14:26:25  <planetmaker> andythenorth, so... did you give that patch I gave you to that end a try?
14:26:38  <planetmaker> that end = insert file as comment?
14:27:18  <planetmaker> in any case I did not receive any feedback, even though I provided it to you as fast as I could write, just an hour after you asked / proposed it
14:28:46  <Ammler> planetmaker: nml does produce nfo, so it would be possible to nml already partially
14:29:02  <Ammler> I.e making a uk signals newgrf with nml
14:29:09  <Ammler> and then using the nfo for the extra grf
14:29:27  <Ammler> to use*
14:29:28  <planetmaker> yes. But keep NML out of OpenGFX sources so far
14:30:27  <planetmaker> e.g. I don't want yet NML source code in the repo
14:30:34  <planetmaker> s/e.g./i.e./
14:31:19  <Ammler> well, you will need nml, if you like to change/fix the signals
14:31:28  <planetmaker> It's fine to use for any newgrf
14:31:40  <planetmaker> But it's not usable for the base sets.
14:31:55  <planetmaker> Because it would mean that no package maintainer can build OpenGFX anymore
14:32:37  <Ammler> hmm, we could make a subdir nml
14:32:42  <planetmaker> Please don't
14:32:54  <FooBar> you can add the nml source code, but just past the nfo output generated with it in the actual source that generates OpenGFX
14:33:10  <Ammler> yes, but where shall I add the nml source?
14:33:20  <FooBar> so basically something for the "source" folder: something that isn't used directly but that might be useful some time
14:33:36  <FooBar> so I suggest either in that folder or in a subfolder of that folder
14:33:52  <Ammler> sprites/nml
14:33:54  <planetmaker> subfolder of the generated (p)nfo
14:34:24  <planetmaker> hm...
14:34:45  <planetmaker> ok. sprites/nml
14:34:58  <Ammler> nml is required to make the signals
14:35:07  <Ammler> but it isn't required to build opengfx
14:35:19  <planetmaker> ?
14:35:30  <planetmaker> That doesn't sound sane
14:35:40  <FooBar> no, source/nml
14:35:46  <Ammler> the source is a png and nml
14:35:59  <Ammler> which then is used to make the pcx and nfo for opengfx
14:36:05  <planetmaker> Ammler, then you need means to convert png->pcx
14:36:08  <FooBar> hmmm...we don't have that in opengfx...
14:36:08  <planetmaker> do that by hand
14:36:10  <planetmaker> beforehand
14:36:20  <FooBar> sprites/source/nml
14:36:25  <planetmaker> nml does no graphics conversion
14:36:32  <Ammler> planetmaker: I do, but we should keep the nml somewhere
14:36:36  <planetmaker> FooBar, no, that is not a good folder
14:36:44  <Ammler> because the pcx isn't templatish
14:36:46  <Ammler> only the png is
14:37:00  <planetmaker> Ammler, just convert the png using gimp?
14:37:12  <planetmaker> or imagemagix?
14:37:32  <planetmaker> Don't start adding image conversion to the required scripts. That's hell a lot of deps I don't want
14:37:34  <FooBar> or just use nml to create the grf, decode it again and use that pcx and nfo for in opengfx
14:37:39  <Ammler> I don't
14:37:49  <planetmaker> FooBar, no. NML just is the means to generate the NFO
14:37:54  <Ammler> but if you decode the grf, you won't have nice sprites anymore
14:38:12  <planetmaker> at least in this case.
14:38:26  <Ammler> planetmaker: no, I don't use the nfo from nml
14:38:33  <Ammler> I generate the grf and decode
14:38:39  <planetmaker> what?
14:38:40  <Ammler> so I have nfo and pcx
14:38:41  <FooBar> well, it's basically how opengfx is created in the first place: from lots of decoded grf files
14:38:58  <planetmaker> Ammler, sorry, that is kinda insane
14:39:28  <planetmaker> Ammler, just convert the png to pcx.
14:39:33  <Ammler> then stay with nfo :-(
14:39:53  <planetmaker> Then use NML to write the NFO. There you can in NML use the nice templates you like
14:39:56  <Ammler> thought it is a good idea, as I like to make a newgrf too
14:40:30  <planetmaker> yes, still. Adding a de-coded newgrf is bollocks
14:40:46  <planetmaker> you have nicely templated sprites in png files, right?
14:40:48  <Ammler> hmm, we have that quite a lot
14:40:52  <planetmaker> Then convert those files to pcx
14:40:56  <planetmaker> Use those.
14:41:05  <Ammler> I don't code the same twice
14:41:31  <planetmaker> Then use NML to easily encode those files as sprites - and chose NFO output
14:41:42  <planetmaker> add that nfo as OpenGFX source
14:42:14  <Ammler> the advantage of nml is using png
14:42:18  <planetmaker> But don't screw up the templating in the graphics files by adding the files twice, once as png and then the same thing as a big monolithic, de-compiled pcx
14:42:40  <planetmaker> IF you want OpenGFX to use NML somewhen it's sane to do it properly now:
14:42:46  <planetmaker> Providing the graphics as PCX
14:42:52  <planetmaker> And have NML only write the used NFO
14:43:07  <planetmaker> But please, please don't just add de-compiled NFO
14:43:15  <planetmaker> That's plain ugly, unreadable and un-commented
14:43:30  <planetmaker> And the latter two points are a no-no for NEW code
14:43:38  <Ammler> well, I do it in nfo, but I don't agree :-P
14:43:41  <planetmaker> And OpenGFX _is_ still NFO
14:43:45  <planetmaker> *sigh*
14:43:49  <planetmaker> You don't get me, right?
14:43:56  <planetmaker> Neither my reasons nor the solution I propose?
14:44:16  <planetmaker> you seem to just have heart 'not NML'
14:44:41  <Ammler> having sources as nml is like having the photoshop as source for pcx
14:45:02  <planetmaker> you can do that. But add the NFO output from NML
14:45:07  <planetmaker> and NOT a de-compiled newgrf
14:45:14  <Ammler> what is the difference?
14:45:22  <planetmaker> the graphic file
14:45:33  <planetmaker> your way: png files + one ugly pcx
14:45:45  <Ammler> you need nml anyway
14:45:46  <planetmaker> my way: no png files, but several pcx
14:45:51  <Ammler> to make changes with the signals
14:46:34  <planetmaker> Ammler, that has to be untrue. OpenGFX must not depend upon NML
14:46:46  <planetmaker> It may be a help to coding parts, yes.
14:47:03  <planetmaker> But the result has to be NFO which is actually commited
14:47:12  <planetmaker> and the NFO should be commented.
14:47:28  <planetmaker> And it is only commented, if you chose NFO output. IIRC and I hope ;-)
14:47:36  <Ammler> no
14:47:48  <planetmaker> If it isn't, it's bad
14:47:49  <Ammler> the nml nfo is as "ugly" as the decoded maybe uglier
14:48:33  <Ammler> so either you code it in nfo or you would use nml as "base"
14:48:47  <Ammler> and if you have changes to that part, you need again nml
14:48:55  <Brot6> FIRS Industry Replacement Set - Revision 1195:6dfc222ec90b: Feature: Supermarket basic code and n... (foobar) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/6dfc222ec90b
14:48:55  <Brot6> FIRS Industry Replacement Set - Feature #479: Supermarket graphics (foobar) @ http://dev.openttdcoop.org/issues/479#change-3221
14:49:05  <planetmaker> Ammler: you may use NML to make the sprite alignment easy by using NML templates.
14:49:09  <Ammler> like if you change a image, you need gimp
14:49:22  <planetmaker> But then please edit the resulting NFO by hand, so that it is commented
14:49:28  <planetmaker> NFO is our source here. Not NML
14:49:44  <planetmaker> So clean NFO is important. Still
14:50:17  <Ammler> so you think decoded nfo is not clean?
14:50:24  <planetmaker> It's not commented
14:50:32  <planetmaker> And I don't want one big image again
14:50:39  <planetmaker> with a random arrangement of signals in the pcx
14:50:47  <Ammler> why?
14:50:52  <Ammler> it isn't source
14:50:55  <planetmaker> Ugly? pcx is source
14:51:06  <Ammler> damn, it isn't that is the whole point
14:51:16  <planetmaker> Ammler, NML is no dependency
14:51:28  <Ammler> but gimp is?
14:51:31  <planetmaker> no
14:51:40  <Ammler> photoshop then?
14:51:56  <Ammler> :-)
14:51:58  <planetmaker> no particular
14:52:23  <planetmaker> you just propose to add ugly source code. Only so that you can write the source code in one particular way
14:52:27  <planetmaker> I find that not acceptable
14:52:54  <planetmaker> It's like providing patches to OpenTTD in word format
14:53:07  <Ammler> I do agree that nfo or pcx which you should be able to change should be nice source
14:53:21  <planetmaker> yes.
14:53:24  <Ammler> but in this case, that nfo and pcx would never be touched
14:53:38  <Ammler> only maybe regenerated
14:53:48  <planetmaker> Nope. Source is not generated.
14:53:55  <Ammler> it isn't source
14:54:04  <planetmaker> pcx+nfo = source of OpenGFX
14:54:14  <Ammler> oh well
14:54:45  <planetmaker> the photoshop files are also source as they might give an easier starting point to editing
14:54:58  <Ammler> like nml could :-(
14:54:58  <planetmaker> But in many cases the pcx have been touched separately. And after photoshopping
14:55:11  <planetmaker> So the pcx are the source and reference really
14:55:20  <planetmaker> They're authorative
14:55:35  <planetmaker> So what you can do is: generate your sprite alignment using NML
14:55:45  <planetmaker> But then the resulting NFO will need hand-editing with comments
14:55:54  <planetmaker> and the images of course have to be in pcx format
14:56:03  <Ammler> and you think, that is easier
14:56:08  <planetmaker> yes
14:56:10  <planetmaker> might be
14:56:12  <Ammler> aslo in respect of future changes
14:56:15  <planetmaker> yes
14:56:49  <Ammler> I change the nml and need again to edit the final nfo
14:56:58  <Ammler> that is bullshit sorry
14:57:12  <Ammler> either you use nml
14:57:12  <planetmaker> Yes, currently. But this is not an NML project
14:57:15  <Ammler> or you use nfo
14:57:26  <planetmaker> If you want it that way: use NFO
14:57:44  <planetmaker> If you already want to prepare for NML: then you currently have to do some extra work
14:57:48  <Ammler> you are really evil :-P
14:57:53  <Brot6> OpenGFX - Bug #657: Enable company colours for sweets factory (2006TTD) @ http://dev.openttdcoop.org/issues/657#change-3223
14:57:54  <planetmaker> Yes.
14:58:25  <planetmaker> But this is an NFO project. And NML does officially not exist and is no development tool for OpenGFX
14:58:40  <planetmaker> if it can become that, I'm the first to implement it.
14:58:49  <Ammler> yes, but gimp is
14:59:51  <Ammler> IMO, this should be a decision of those people working with it
15:00:00  <Ammler> why don't we need to care about others?
15:00:22  <Ammler> as long as we don't make it a building requirement?
15:01:08  <Ammler> -n't
15:01:25  <FooBar> according to GPL, source is "preferred form of editing". If using NML to create grf, then decoding that and copy/paste to OpenGFX, than that IMO is "preferred form of editing"
15:01:49  <Ammler> yes, the nml is in the source,
15:02:08  <Ammler> it is needed, if you like to change it later anyway
15:02:31  <Ammler> it is like openttd does have openttd.grf in the source
15:02:46  <FooBar> true, or you just tweak the pcx and nfo (well, if someone were to fork OpenGFX and wanted to change that particular part)
15:03:25  <FooBar> if you like to do it in pure NFO, than that is "preferred form of editing" also
15:03:46  <Ammler> yes, I do just not agree, that we need to be so strict
15:17:37  <Brot6> FIRS Industry Replacement Set - Revision 1196:f84f66dd7f77: Feature: Retail Market basic code and... (foobar) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/f84f66dd7f77
15:17:37  <Brot6> FIRS Industry Replacement Set - Feature #477: Retail Market graphics (foobar) @ http://dev.openttdcoop.org/issues/477#change-3224
15:19:43  <Brot6> OpenGFX - Feature #839: 4737-4742: Fizzy drink factory (2006TTD) @ http://dev.openttdcoop.org/issues/839#change-3225
15:32:39  <Ammler> http://dev.openttdcoop.org/projects/opengfx/repository/entry/sprites/nfo/extra/extra-signals.pnfo <-- does already have british semaphores?
15:34:14  <Ammler> that file is cryptic
15:38:07  *** Seberoth has quit IRC
15:42:37  *** Seberoth has joined #openttdcoop.devzone
15:44:11  <FooBar> Ammler: yes we have, the same as in OpenTTD_extra (both types drawn by mb)
15:45:42  <Brot6> FIRS Industry Replacement Set - Revision 1197:326c09193489: Feature: Sugar Refinery basic code an... (foobar) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/326c09193489
15:46:58  <Ammler> FooBar: but they aren't british, those are rightsided
15:47:14  <FooBar> ?
15:47:30  <FooBar> there's two types of semaphores, one with the arm on the left and one with the arm on the right
15:47:50  <Ammler> where are the others?
15:48:07  <Brot6> FIRS Industry Replacement Set - Feature #474: Sugar Refinery graphics (foobar) @ http://dev.openttdcoop.org/issues/474#change-3226
15:48:38  <FooBar> they should be in there somewhere, guarded with some action 7; the semaphores with arm on left show when drive side is set to left
15:48:53  <Ammler> hmm
15:49:31  <FooBar> I checked in the game, not in the source, so where they are in the source I don't know
15:49:40  <Ammler> you can have such ingame?
15:49:57  <Ammler> I guess, it matters how you start a game then?
15:50:48  <Ammler> I always thought, we will add the Born Acorn signals and not replace others
15:51:50  <FooBar> you need to change the drive side, but you can only do that before starting the game
15:52:08  <Ammler> I was able to change that after
15:52:11  <Ammler> :-o
15:52:31  <Ammler> I am still are
15:52:32  <FooBar> that's possible now?
15:52:32  <Brot6> FIRS Industry Replacement Set - Revision 1198:5af479cd7ddc: Fix (r1197): Sugar Refinery needn't b... (foobar) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/5af479cd7ddc
15:52:36  <FooBar> hmmm
15:52:56  <Ammler> I wasn't, then I loaded the save and I am able to change
15:53:01  <FooBar> anyways, we might need to include some check with patch flag 3B
15:53:10  <FooBar> (if that isn't in there already)
15:53:21  <FooBar> that is the "signalsontrafficside" switch
15:53:51  <Ammler> are you really sure, there are both types already in the game?
15:54:11  <FooBar> I can see both types, so yes
15:54:43  <Ammler> hmm, true
15:54:52  <Ammler> but only, if I start a new game
15:55:00  <FooBar> possibly
15:55:01  <Ammler> else they just change the side but keep the same
15:55:23  <FooBar> I had to do that as well (otherwise I don't think extra grf is reloaded, as that is a requirement for the signals to change
15:55:37  <FooBar> )
15:56:02  <FooBar> also there already is a signal on traffic side check in it
15:56:08  <FooBar> so that should be alright then
15:56:19  <Ammler> you can reapply newgrfs
15:56:23  <Ammler> to realod the extra grf
15:56:45  <FooBar> ok, haven't tried that
15:58:04  <FooBar> also I forgot what I was doing...
15:58:27  <Ammler> sorry :-P
15:58:41  <Ammler> something with FIRS :
15:58:53  <FooBar> I knew that :D
15:59:15  <Ammler> nobody uses FIRS, so rather code opengfx :-P
15:59:48  <FooBar> I use FIRS...
15:59:57  <FooBar> but then I use OpenGFX as well...
16:00:20  <FooBar> andy doesn't use OpenGFX, let him code FIRS then :P
16:00:29  <Brot6> FIRS Industry Replacement Set - Revision 1199:1b0e80f79be6: Fix (r1197): Sugar Refinery needn't h... (foobar) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/1b0e80f79be6
16:01:46  <Ammler> yeah, he hasn't something else to do anyway
16:03:35  <FooBar> no, only like three other sets
16:05:55  <FooBar> I only have like 6 sets I can work on :o
16:06:35  <FooBar> anyways, dinner :)
16:06:52  <Ammler> isn't left-right already supported by openttd
16:07:14  <Ammler> seems both types are in the openttd.grf too
16:08:34  <Ammler> so the needed reload is not because of Action7
16:13:30  <Ammler> you have clima switches there only
16:17:40  <Ammler> hmm, ogfx uses 2 red 1 green, original 1 red 2green
16:17:48  <Ammler> for presignals
16:20:22  <Brot6> firs: update from r1190 to r1199 done (12 errors) - http://bundles.openttdcoop.org/firs/nightlies/r1199
16:21:43  <Brot6> nforenum: update from r469 to r470 done - http://bundles.openttdcoop.org/nforenum/nightlies/r470
16:21:52  <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), newgrf_makefile (r127), nml (r670), nutracks (r93), ogfxplus (r41), opengfx (r482), openmsx (r97), opensfx (r97), snowlinemod (r15), swedishrails (r141), transrapidtrackset (r15), worldairlinersset (r659)
16:22:27  <Brot6> 2cctrainset: compile of r580 failed - http://bundles.openttdcoop.org/2cctrainset/nightlies/ERROR/r580
16:28:54  <planetmaker> FooBar, 'preferred form of editing' does also imply that there's a way to build the thing from that source
16:29:00  <planetmaker> NML does not provide that.
16:29:16  <planetmaker> If we now add NML, we can totally forget about getting this set into distros
16:29:20  <planetmaker> It breaks everything
16:29:39  <planetmaker> And no, we cannot have NML as a dependency
16:29:41  <planetmaker> Not yet
16:30:05  <planetmaker> So we need a way to get clean NFO code
16:30:19  <planetmaker> how you get *that*. That's up to the author's choice
16:30:32  <planetmaker> But de-compiled things declared as source: that's not 'preferred'
16:30:57  <planetmaker> That's like saying I write assembler programmes by writing it in C++ and then using a de-compiler
16:30:58  <FooBar> planetmaker: I guess you're right at that
16:31:03  <planetmaker> Certainly not 'preferred'
16:31:30  <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: 32bpp-extra (1 errors) (Diffsize: 13), airportsplus (Diffsize: 13), basecosts (Diffsize: 11), comic-houses (3 errors) (Diffsize: 13), firs (12 errors), fish (6 errors) (Diffsize: 13), heqs (Diffsize: 13), metrotrackset, newgrf_makefile, nutracks (13 errors), opengfx, snowlinemod (Diffsize: 13), transrapidtrackset (Diffsize: 11), worldairlinersset
16:31:30  <Brot6> (Diffsize: 13)
16:33:03  <FooBar> Ammler: I believe the semaphore stuff in opengfx is the exact same as the semaphore stuff in openttd.grf But there is action7 a little further down the file, from the top of my head around line 217 and then some other time later on for toyland
16:34:32  <Ammler> yes
16:34:43  <Ammler> that has nothing to do with left-right side traffic
16:34:46  <FooBar> As for light signals: it might be a good idea to keep the same standard as openttd.grf. That allows creating a more uniform manual while using both base sets for screenshots
16:40:32  <Ammler> well, I never really compared that
16:40:38  <Ammler> I guess, ti doesn't really matter
16:41:00  <Ammler> you say red or green, not 2green or 2red
16:41:13  <FooBar> true
16:41:46  <FooBar> it's mostly the stuff about PBS that is confusing; there's still a yellow light in the screenshot while both base sets don't have that any more
16:42:49  <FooBar> Also I don't think having exactly the same signal aspects is crucial. "similar" is good enough for me
16:44:24  <Ammler> well, we code the signals we have now and then will see after the release :-)
16:44:47  <FooBar> fine with me :)
16:45:38  <FooBar> maybe the manual should get a 'signal equivalency table', which also can include signals of different kinds of signal sets
16:45:43  <FooBar> I'm not making that though
16:46:22  <Ammler> the pbs semaphores are indeed bad in opengfx
16:46:42  <Ammler> :-D
16:48:49  <FooBar> maybe copy those from openttd.grf (again)
16:49:26  <FooBar> hmmm...those might already be the same...
16:53:54  <Ammler> yes, they are also bad in openttd.grf :-)
16:54:21  <Ammler> nobody uses semaphores so nobody might care
16:55:16  <Ammler> the only difference to the generic signals is a one pixel orange and green light
17:01:04  <FooBar> there's a hard-to-see diagonal stripe on the back as well
17:01:18  <FooBar> as you can read, I /do/ use semaphores
17:01:59  <Ammler> :-)
17:03:27  * FooBar thinks Andy didn't think r1200 was going to be this type of fix:
17:04:20  <Brot6> FIRS Industry Replacement Set - Revision 1200:c9b599d1ffc2: Fix: template_accept_only_action_23_A... (foobar) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/c9b599d1ffc2
17:20:30  <DJNekkid> anyone know what the most pressing nutracks-issue is?
17:26:07  <Brot6> Nutracks - Revision 94:9e6e1aa61dbd: Fix: Wrong text id# on a handfull of tracks (DJNekkid) @ http://dev.openttdcoop.org/projects/nutracks/repository/revisions/9e6e1aa61dbd
17:32:40  <FooBar> fixing whatever errors/warnings nforenum spits... or did r94 fix that all?
17:34:01  <Ammler> after you removed all //@@DISABLE
17:35:09  <FooBar> you're allowed to disable warning 100, but none other than that, as I didn't have to in metrotracks either :P
17:36:59  <Brot6> FIRS Industry Replacement Set - Revision 1201:52523f311c21: Feature: Cane Plantation basic code a... (foobar) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/52523f311c21
17:37:00  *** Alberth has joined #openttdcoop.devzone
17:38:45  <Brot6> FIRS Industry Replacement Set - Feature #460: Cane Plantation graphics (foobar) @ http://dev.openttdcoop.org/issues/460#change-3227
17:46:23  <DJNekkid> what about 144? (color codes in action8)
17:50:25  <FooBar> upgrade your renum ;)
17:52:03  <FooBar> http://www.openttd.org/en/download-nforenum-nightly
17:52:05  <DJNekkid> apparently all warnings were //'ed :)
17:52:11  <DJNekkid> just me not realizing it :)
17:58:13  <Brot6> FIRS Industry Replacement Set - Feature #1256 (New): Add more layouts to Cane Plantation (foobar) @ http://dev.openttdcoop.org/issues/1256
18:04:23  <Brot6> FIRS Industry Replacement Set - Revision 1202:4610632c3f72: Feature: Arable Farm now produces Sug... (foobar) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/4610632c3f72
18:04:23  <Brot6> FIRS Industry Replacement Set - Feature #1257 (New): sugar cane should be called sugar beet in cl... (foobar) @ http://dev.openttdcoop.org/issues/1257
18:04:23  <Brot6> FIRS Industry Replacement Set - Feature #913 (Closed): Arable farm should also produce Sugar Beet... (foobar) @ http://dev.openttdcoop.org/issues/913#change-3230
18:04:36  <Ammler> grfcodec is so slow
18:18:05  <Ammler> the ingame sprite aligner still rocks :-)
18:18:28  <Ammler> would be nice to have a display for the sprite sizes
18:20:20  <Ammler> the offset I use has no logic, is that good?
18:28:28  <andythenorth> hi hi
18:30:22  <Rubidium> Ammler: maybe -O3 in your local flags might help?
18:30:45  <FooBar> hi andythenorth
18:31:04  <Ammler> Rubidium: it just seems slow, when you recode many times
18:31:16  <Ammler> and the base grf is big
18:31:48  <FooBar> andythenorth, I'm not so sure about the cane plantation if also the arable farm produces cane; both are basically the same thing
18:32:42  * andythenorth typing left handed, baby sleeping on right arm :P
18:32:57  <FooBar> :)
18:33:25  <Alberth> that's better than a sleeping right arm :)
18:33:31  <FooBar> :D
18:34:32  <FooBar> beware that one might result in the other
18:35:36  <andythenorth> FooBar: yup cane plantation might br
18:35:42  <andythenorth> be rednundant
18:35:53  <Brot6> OpenGFX - Revision 483:bd557a1795a7: Feature #840, #280: template for signals (Ammler) @ http://dev.openttdcoop.org/projects/opengfx/repository/revisions/bd557a1795a7
18:36:28  <FooBar> if so, then I'm not trying to guard it form other climates and such until we're certain
18:36:45  <andythenorth> I think we do without it
18:37:25  <FooBar> better leave it in some time, as introducing it and removing it 2 revisions later is a bit weird :P
18:37:31  <andythenorth> I want to avoid climate specific stuff mostly
18:37:59  <andythenorth> sugar cane / sugar beet is a valid climate specific thing
18:38:30  <andythenorth> I wonder what to do with cotton...
18:39:11  <andythenorth> lets revisit import/export cargos...
18:39:18  <Brot6> FIRS Industry Replacement Set - Feature #1258 (New): reconsider cane plantation (foobar) @ http://dev.openttdcoop.org/issues/1258
18:39:37  <andythenorth> what do we think about cargos that go 'off map'?
18:39:38  <FooBar> IMO climate specific stuff should have an equivalent accepting and producing exactly the same in all climates. Just graphics/industry name (and possible other properties) can be different
18:40:52  <FooBar> I'm not sure about import/export
18:41:32  <andythenorth> it's not traditional TTD world
18:41:44  <andythenorth> no cargo off map is the tradition
18:41:44  <FooBar> that, and I'm not sure if it's good gameplay
18:42:02  <FooBar> it could work with limited cargo
18:42:20  <andythenorth> I've got some valid uses for t
18:42:34  <FooBar> e.g. importing things in temperate that are only available in FIRS-tropic
18:42:40  <andythenorth> yup
18:42:51  <andythenorth> I want to do a UK Economy
18:42:54  <FooBar> that both introduces and again limits climate specific stuff
18:43:08  <andythenorth> it would need to import bauxite and cotton
18:44:18  <FooBar> let's look at primary cargos that are normally climate-specific
18:44:30  <FooBar> or maybe country-specific
18:44:34  <andythenorth> can you list...
18:44:42  <andythenorth> my typing is...impaired :P
18:44:52  <FooBar> :)
18:45:12  <FooBar> I'll just walk trough all primary cargo's and then you can go y or n ;)
18:45:22  <FooBar> or m for maybe
18:45:28  * Ammler definitly hates signals now
18:45:32  <FooBar> I'll add my opinion directly to it
18:45:35  <FooBar> coal m
18:46:00  <andythenorth> y is for specific?
18:46:20  <FooBar> y is for could be importable
18:46:42  <FooBar> I mean should me importable...
18:46:52  <FooBar> m is for /could/...
18:47:10  <FooBar> assuming we do some import feature
18:47:11  <andythenorth> coal m (tropic island...)
18:47:18  <FooBar> iron ore y
18:47:56  <andythenorth> y
18:48:06  <FooBar> bauxite y
18:48:15  <andythenorth> y
18:48:18  <FooBar> grain m
18:48:40  <FooBar> maybe even y
18:48:49  <andythenorth> y (export - canada)
18:48:57  <FooBar> ok, y it is
18:49:01  <FooBar> sugar cane y
18:49:25  <andythenorth> y
18:49:31  <andythenorth> hmmm
18:49:33  <andythenorth> n
18:49:50  <andythenorth> it's not shipped far in raw form
18:50:15  <FooBar> hmmm ok
18:50:21  <andythenorth> (grain terminals http://pcgladiator.blogspot.com/2009/03/thunder-bays-grain-terminals.html)
18:50:22  <Webster> Title: Manufactured landscapes: Thunder Bay's grain terminals (at pcgladiator.blogspot.com)
18:50:42  <FooBar> sand n
18:50:52  <andythenorth> n
18:51:00  <FooBar> gravel n
18:51:13  <andythenorth> n
18:51:15  <FooBar> fish y
18:51:20  <andythenorth> hmm
18:51:27  <andythenorth> dunno
18:51:35  <FooBar> m then :)
18:51:42  <FooBar> oil
18:51:46  <andythenorth> y
18:51:58  <FooBar> I meant "oil y" :P
18:52:23  <FooBar> I'm starting to realize that importing also could apply to secondary cargoes...
18:52:31  <FooBar> livestock n
18:52:34  <FooBar> milk n
18:52:44  <andythenorth> n n
18:52:58  <FooBar> fruit and veggies n
18:53:11  <andythenorth> n
18:53:26  <FooBar> food? :P
18:53:38  <andythenorth> not sure
18:53:48  <Ammler> I guess, it wasn't a good idea to start with semaphores
18:54:13  <FooBar> well, if all climates have livestock and fruit/vegetables, we shouln't be importing food: too easy
18:54:24  <FooBar> wood
18:54:30  <FooBar> m
18:54:45  <andythenorth> m
18:54:50  <FooBar> lumber
18:54:59  <FooBar> same as wood I guess
18:55:01  <andythenorth> m
18:55:11  <FooBar> chemicals
18:55:13  <FooBar> y
18:55:20  <andythenorth> y
18:55:25  <FooBar> fuel oil
18:55:26  <FooBar> y
18:55:29  <andythenorth> y
18:55:34  <FooBar> cotton y
18:55:36  <FooBar> wool y
18:55:57  <Ammler> oh sorry for disturbing your big voting round :-P
18:56:13  <FooBar> no problem, we're just ignoring you anyways at the moment :D
18:56:16  <andythenorth> i suppose for most of these a valid reason could be found for a certain economy
18:56:30  <FooBar> exactly
18:56:44  <FooBar> that makes it too difficult wrt industry ids and cargo ids I guess
18:57:00  <andythenorth> nah, just use the economy system
18:57:06  <andythenorth> it eill work fine
18:57:10  <andythenorth> will /s
18:57:30  <FooBar> it would need some dynamic allocation at least
18:57:38  <andythenorth> climate specific == bad, economy specific == good
18:57:56  <FooBar> that is a good conclusion
18:58:13  <andythenorth> exceptions are sugar cane / beet
18:58:26  <FooBar> that will be just a name change in tropic
18:58:54  <FooBar> maybe change the cargo RSGR as in "raw sugar"
18:59:03  <andythenorth> good idea
18:59:06  <andythenorth> i know how to handle cotton
18:59:24  <FooBar> should I guess or can you type? :P
18:59:51  <andythenorth> 1. don't feature it in 'basic' firs
19:00:23  <andythenorth> 2. make a cotton plantation in tropic, an import dock in other
19:00:24  <Brot6> OpenGFX - Revision 484:19c12959a990: Fix (rPREV): switch vertical signals (Ammler) @ http://dev.openttdcoop.org/projects/opengfx/repository/revisions/19c12959a990
19:00:26  <FooBar> I think the sheep farm should be a cotton farm in tropic and wool should be cotton in tropic and be done with that
19:00:33  <andythenorth> nah
19:00:39  <andythenorth> australia...
19:00:43  <FooBar> hmmm
19:01:11  <FooBar> import dock works for me as well
19:02:25  * FooBar ponders about a llama farm
19:02:32  <andythenorth> :D
19:02:54  <andythenorth> we could do a 'novelty' economy
19:02:57  <FooBar> to replace the sheep farm in tropic and produces whatever the sheep farm produces...
19:04:00  <FooBar> hmmm...llama are mainly pack and meat animal, while alpaca are mainly wool animal...
19:04:49  <andythenorth> ostrich?
19:04:59  <FooBar> new cargo: eggs
19:05:30  <FooBar> that in turn calls for a chicken farm...
19:06:17  <andythenorth> what unit ?
19:06:31  <FooBar> piece I guess...
19:06:44  <andythenorth> box?
19:07:25  <FooBar> probably
19:07:39  <FooBar> eggs are not shipped in bulk without any protection
19:09:45  <FooBar> anyways, I think import could work if amount of cargos are limited and that imported cargo cannot be exported
19:11:20  <andythenorth> yup
19:11:48  <andythenorth> and not in the default economies
19:12:39  <FooBar> agreed, only in specific economies where import actually adds to realisticness of gameplay
19:14:45  <andythenorth> warehouses or docks?  or both?
19:16:05  <FooBar> maybe call it 'import terminal' and have different representations of it
19:16:56  <FooBar> but then warehouses always work, either next to docks or next to airport
19:17:15  <andythenorth> we could have d
19:17:26  <andythenorth> sprites that vary by coast
19:17:35  <andythenorth> so
19:17:39  <Brot6> OpenGFX - Revision 485:9900727c7fce: Feature #840: generic uk semaphores from Born Acorn (Ammler) @ http://dev.openttdcoop.org/projects/opengfx/repository/revisions/9900727c7fce
19:17:43  * andythenorth baby woke up
19:20:30  * andythenorth two hands
19:20:54  <Brot6> OpenGFX - Bug #280: standard signals (Ammler) @ http://dev.openttdcoop.org/issues/280#change-3232
19:21:13  <andythenorth> we could do an 'import terminal' that has a core set of buildings, and also shows other sprites depending on whether built on coast
19:21:57  <FooBar> that would be nice
19:22:08  <andythenorth> we could do varact 2 probability to make it prefer coasts
19:22:45  <FooBar> andythenorth: somebody pm'ed me to check this post, but I'm not sure of the answer... http://www.tt-forums.net/viewtopic.php?p=897012#p897012
19:22:47  <Webster> Title: Transport Tycoon Forums • View topic - FIRS Industry Replacement Set - v0.3 Officially Released (at www.tt-forums.net)
19:23:06  <andythenorth> FooBar: me neither :P
19:23:09  <andythenorth> I haven't tested it
19:23:17  <FooBar> ok, then I'll reply that :P
19:23:39  <andythenorth> code says 0 0 3 will allow closure of secondary industry
19:23:50  <andythenorth> primary industry shouldn't close because there's no production decreases
19:24:26  <andythenorth> secondary industry will close if no cargo for n months
19:27:01  <Ammler> so lame, he is reading the readme
19:27:14  <FooBar> :)
19:27:48  <FooBar> otherwise you could just say "what does the readme tell you"
19:28:01  <andythenorth> I think the reply would be "where's the fricking readme?"
19:28:07  <andythenorth> the readme concept is broken
19:28:40  <Ammler> wow, really fast industry
19:28:51  <Ammler> is that the speed of the smoke?
19:28:58  <andythenorth> what smoke :P
19:28:58  <FooBar> I think the name is the problem: people don't want to be pushed around with "read this, read that, read me"
19:29:13  <andythenorth> the issue is...where is the readme anyway?  And how should I know to look for it?
19:29:26  <andythenorth> But I have moaned about this before :)
19:29:29  <FooBar> I don't know, there's no power station in firs...
19:29:47  <Ammler> http://bundles.openttdcoop.org/firs/releases/LATEST/readme.txt
19:30:10  <andythenorth> Ammler: I know :)
19:30:33  <Ammler> but this guy says, he read the readme
19:30:38  <andythenorth> ah
19:30:41  <andythenorth> well
19:31:21  <andythenorth> FooBar: we still have to reimplement all the default animations, and lots of new ones :P
19:31:39  <FooBar> I put that at "low priority"
19:32:15  <FooBar> for default industries, I think it's best to actually recode all layouts, as that also gives proper hooks for the varaction2 stuff we want to add
19:32:37  <Ammler> I don't see speed here
19:32:51  <andythenorth> FooBar: yes, that's going to be necessary
19:32:58  <andythenorth> Ammler: you have a newer build
19:33:04  <FooBar> old openttd has speed, new openttd has a date; maybe the wrong date, but a date ;)
19:33:36  <Ammler> why not disable firs on old builds?
19:33:45  <andythenorth> why bother?
19:33:49  <andythenorth> but we could
19:34:03  <Ammler> so wouldn't need to answer such questions :-)
19:34:17  <andythenorth> easily answered though
19:34:36  <andythenorth> the alternative is "why doesn't FIRS work on the 1.x releases?"
19:34:49  <Ammler> well, that would the firs tell you
19:34:55  <FooBar> it does work on 1.0.3...
19:35:09  <FooBar> the date stuff is backported
19:35:14  <Ammler> you can "customize" the message for ActionB
19:35:48  <FooBar> no need "requires OpenTTD 1.0.3/rxxxxx" would be good enough
19:35:55  <Ammler> yes
19:36:33  <FooBar> I don't know if there are other things in trunk that FIRS needs that are not in 1.0.3...
19:36:47  <FooBar> clustering is probably not critical if that isn't in
19:37:48  <FooBar> andythenorth: do you remember all things that were added to OpenTTD due to FIRS needing it?
19:38:59  <Ammler> get them to include custom fields
19:40:08  <Ammler> there is a simple reason, you should at least support all default industries too
19:40:21  <Ammler> just so someone can easy add the grf to a running game
19:40:50  <andythenorth> FooBar: I don't remember
19:40:57  <andythenorth> clustering uses a cb that fails safely
19:41:00  <andythenorth> or so I believe
19:41:29  <andythenorth> parameter settings gui fails safely
19:41:31  <Brot6> FIRS Industry Replacement Set - Feature #1257 (Closed): sugar cane should be called sugar beet in... (foobar) @ http://dev.openttdcoop.org/issues/1257
19:41:31  <Brot6> FIRS Industry Replacement Set - Revision 1203:0a83d2c9e446: Feature: rename sugar cane to sugar b... (foobar) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/0a83d2c9e446
19:41:31  <Brot6> FIRS Industry Replacement Set - Feature #1257 (Closed): sugar cane should be called sugar beet in... (foobar) @ http://dev.openttdcoop.org/issues/1257#change-3233
19:41:44  <Ammler> hmm, seems not possible
19:41:44  <andythenorth> parameter settings gui is very nice, and frosch123 yexo etc should get cookies
19:41:56  <FooBar> darn, I just ate all cookies...
19:42:34  <Ammler> the whole newgrf debugging is also dedicated to any
19:42:37  <Ammler> andy*
19:42:46  <andythenorth> the debugging is awesome :D
19:43:00  <andythenorth> even reload_newgrfs is an epic win
19:43:11  <andythenorth> FooBar: - are you now familiar with the debug stuff?
19:43:11  <Ammler> rescan would be nice
19:43:16  <Ammler> and sprite sizes
19:43:25  <FooBar> andythenorth: I have it enabled but hardly ever look at it
19:43:49  <andythenorth> reload_newgrfs in console will save your sanity
19:44:01  <andythenorth> also if you do any layouts, the debug tool is invaluable
19:44:56  <andythenorth> FooBar: FIRS 0.4 is looking pretty chunky.  51 tickets
19:45:03  <andythenorth> I wondered about a smaller release then move to 0.5
19:45:23  <andythenorth> but grf ID will need bumping for 0.4, then maybe again for 0.5...might be unpopular :P
19:45:40  <Ammler> did ever someone complain about?
19:46:14  <FooBar> maybe do most code stuff in 0.4 and new layouts and graphics and things like that in 0.5
19:46:34  <FooBar> then even if you have to bump the grfid, there is no real need to upgrade running 0.4 games
19:46:41  <FooBar> just use 0.5 for new game
19:47:09  <andythenorth> Ammler: MB complained
19:47:23  <Ammler> really :-o
19:47:25  <Ammler> in your thread?
19:47:34  <FooBar> about that he cannot use FIRS in TTDPatch?
19:47:37  <andythenorth> in the DB set FIRS thread
19:47:42  <Ammler> ah
19:47:52  <Ammler> well, that is something else
19:48:11  <Ammler> he complained about that you changed the cargos (again)
19:48:31  <FooBar> I now changed it again...
19:48:36  <Ammler> we had so big fights with him so he makes a firs extension
19:48:49  <Ammler> IMO, YOU should make that extesnion
19:49:08  <FooBar> if only mb would open-source his code, that would be little effort
19:49:24  <Ammler> what you need his source for?
19:49:46  <FooBar> I don't fancy having to look up all vehicle IDs and basically redo what he did
19:50:00  <andythenorth> I've voted with my feet.  I don't use DB set.
19:50:04  <andythenorth> is it good?
19:50:11  <Ammler> :-)
19:50:21  <FooBar> is it good he asks... :P
19:50:31  <andythenorth> it's the best?
19:50:38  <andythenorth> better than NARS 2?
19:50:40  <Ammler> until 2cc definitly
19:50:50  * Ammler doesn't like pikka sets
19:50:57  <Ammler> they are slow
19:51:07  <Ammler> too realistic
19:51:15  <FooBar> that I don't know, but it basically is to Germany-oriented countries what UKRS is to UK-oriented countries
19:51:33  <Ammler> well, "not like" i wrong
19:51:34  <andythenorth> I have a note here to tell grf authors about planned cargo changes / introductions where possible
19:51:38  <Ammler> is*
19:52:02  <Ammler> andythenorth: pikka sets are good for sp
19:52:03  <FooBar> andythenorth: tell them that SGCN is renamed to RSGR
19:52:15  <FooBar> that reminds me to update the newgrf wiki...
19:52:18  <Ammler> dbset and 2cc is best for MP
19:52:43  <Ammler> jpset is simply awesome
19:53:01  <andythenorth> FooBar: did you update the TTDP wiki?
19:53:06  <FooBar> I'm on it now
19:53:12  <andythenorth> I'll do my site now
19:53:29  <Ammler> you have too many sources for your infos :-)
19:54:00  <andythenorth> well...maybe
19:54:11  <andythenorth> it hasn't cause many problems so far though
19:54:16  <andythenorth> redmine is good for tickets
19:54:20  <andythenorth> my site is good for design
19:54:27  <andythenorth> everything else is just....everything else
19:54:32  <Ammler> :-)
19:55:10  <andythenorth> my site is a custom CMS which understands all the cargos / industries, otherwise I'd just use Redmine
20:08:03  <FooBar> hmmm...seems FIRS claims to be compatible with some ECS combinations...
20:08:43  <FooBar> shall we remove that and just deny all ECS compatibility? I haven't been paying attention to any kind of compatibility anyways...
20:08:54  <andythenorth> you wrote that code :)
20:09:09  <andythenorth> it's semi-compatible with ECS construction vector by Pikka
20:09:29  <andythenorth> for me it's "FIRS or nothing"
20:09:35  <andythenorth> except for add-ons
20:09:54  <FooBar> I know I wrote it...
20:10:01  <FooBar> let me unwrite it...
20:10:05  <FooBar> :D
20:10:15  <FooBar> what do you mean by semi-compatible?
20:10:23  <andythenorth> the claypit breaks
20:10:28  <andythenorth> and the brickworks
20:10:35  <andythenorth> so not very compatible :P
20:10:39  <FooBar> I'd call that incompatible :P
20:11:02  <FooBar> I'll keep the checks for na city set and canset in; those only need a specific parameter setting
20:15:16  <andythenorth> ok
20:40:22  * andythenorth ponders doing a ticket
20:42:23  <FooBar> do one
20:42:41  <Brot6> FIRS Industry Replacement Set - Bug #1242 (Closed): Farm snow check fails if tile is bulldozed (andythenorth) @ http://dev.openttdcoop.org/issues/1242#change-3234
20:42:50  <andythenorth> that one was already done :P
20:44:38  <FooBar> quick one, I like those :)
20:45:15  <andythenorth> FooBar: you can reuse your can plantation code for the cotton plantation
20:45:46  <FooBar> sure, I also reused it for the cane plantation which we probably end up removing
20:46:07  <andythenorth> that's what I meant :)
20:46:20  <andythenorth> your cane plantation can be the cotton plantation (for now)
20:46:24  <andythenorth> fields need to change
20:46:52  <andythenorth> blacksmith needs a 'don't build after xyz' date
20:48:03  <Brot6> FIRS Industry Replacement Set - Feature #1259 (New): Blacksmith needs a "don't build after xyz" date (andythenorth) @ http://dev.openttdcoop.org/issues/1259
20:49:19  <Brot6> FIRS Industry Replacement Set - Revision 1204:236ea733444e: Feature: FIRS now requires OpenTTD 1.... (foobar) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/236ea733444e
20:50:30  <FooBar> andythenorth: did I ask to continue including all missing industries as part of http://dev.openttdcoop.org/issues/1171 or is that issue done now?
20:51:13  <andythenorth> FooBar: I think it's done
20:52:03  <FooBar> so we don't need all industries added for 0.4?
20:53:35  <andythenorth> nah not all
20:53:45  <FooBar> Also, we can switch back to bazaar now. The bug I filed 1.5 years ago is now fixed :P
20:53:53  <andythenorth> :)
20:54:14  <andythenorth> best to get 0.4 done and play some test games.  I'm looking at the industry minimap now, it's quite a lot of industries :)
20:54:27  <FooBar> more than 40 now :o
20:54:28  <Ammler> FooBar: there is a Action7 with side
20:54:46  <FooBar> side?
20:55:04  <Ammler> -1 * 0   07 85 01  3B F2 //skip if signals not on traffic side
20:55:05  <Ammler> -1 * 0   07 86 01  04 F1 //skip if drive side not right
20:55:29  <FooBar> oh that, yes I tried to tell you before...
20:55:42  <Ammler> but I see not why
20:56:10  <FooBar> to differentiate between British and German signal style
20:56:23  <FooBar> I mean semaphore style
20:56:46  <Ammler> but the signals pcx from openttd.grf does also have 2 different styles
20:57:01  <Ammler> oh, maybe they do that also with Action7
20:57:07  <FooBar> British is always defined, and then IF signals on traffic side AND drive on right, they are redefined with German semaphore style
20:57:32  <Ammler> and why do you skip that for toyland?
20:57:50  <FooBar> openttd also uses action7, I copied the very code from openttdw.grf
20:58:08  <Ammler> there is no "w" anymore ;-)
20:58:15  <FooBar> back then there was ;)
20:58:19  <Ammler> :-)
20:58:35  <FooBar> the toyland skip I'm not sure...
20:59:54  <FooBar> maybe because toyland was sometime planned to have purple poles for all signals?
21:00:19  <Ammler> yes, you have extra toyland code there
21:00:21  *** Alberth has left #openttdcoop.devzone
21:01:20  <Ammler> I cut that off and make a special toyland nfo
21:01:22  <FooBar> I see, the extra toyland code is there because the toyland PBS signals are different
21:01:56  <FooBar> so there is no redundant code
21:02:09  <FooBar> but you can split if you like, that's no problem
21:03:55  <Brot6> FIRS Industry Replacement Set - Feature #1260 (New): Adjust various map colours (andythenorth) @ http://dev.openttdcoop.org/issues/1260
21:05:11  <Brot6> FIRS Industry Replacement Set - Feature #1171 (Closed): add missing industries as boxes (foobar) @ http://dev.openttdcoop.org/issues/1171#change-3235
21:05:23  <FooBar> andythenorth: I set windmill to blue because it's a blue box, but I agree that it isn't ideal
21:05:47  <andythenorth> makes sense, but I couldn't find one on the map :)
21:06:14  <FooBar> you can only see at closest zoom level (because it's 1-tile) and even then it's a bit tricky :P
21:06:28  <Ammler> I am quite suprised to find Action7 in the openttd.grf
21:06:35  <FooBar> while adding the industries, I noticed that there are too little colours :P
21:06:42  <andythenorth> yup
21:06:46  <Ammler> change to DOS :-P
21:06:56  <andythenorth> some ranges can't be used, clash with map / water / towns
21:07:10  <FooBar> ...too little /distinguishable/ colours ;)
21:07:38  <Ammler> hmm, you should really consider switching the palette
21:08:13  <FooBar> changing all pcx files is not fun :(
21:08:26  <andythenorth> nah
21:08:33  <Ammler> that is a bulk job
21:08:44  <andythenorth> however...I'm considering renaming all the filenames beginning 'i_'
21:08:59  <andythenorth> it makes typing to open the file very slow :o
21:09:00  <FooBar> suggestion?
21:09:09  <FooBar> ah...
21:09:11  <andythenorth> just don't prefix them
21:09:32  <FooBar> use a GUI to open the files...
21:09:34  <FooBar> :P
21:09:51  <andythenorth> I do use a GUI :P
21:09:58  <FooBar> that's why I put the i_ there in the first place, so that all industries sit next to each other...
21:10:11  <andythenorth> nice idea, but not necessarily a time saver :)
21:10:35  <FooBar> for me it is if I need to find any of the other files...
21:10:35  <andythenorth> frick
21:10:38  <andythenorth> merge issues
21:10:42  <FooBar> :D
21:10:50  <FooBar> ids.pnfo?
21:10:53  <andythenorth> dunno
21:11:03  <andythenorth> this is a new one on me: abort: branch 'default' has one head - please merge with an explicit rev
21:11:59  <andythenorth> planetmaker: Ammler...advice? ^
21:12:21  <Ammler> opengfx?
21:12:29  <andythenorth> FIRS
21:12:35  <Ammler> hg heads
21:12:52  <FooBar> if you dump all industries in a subfolder and then get rid of the i_ I'd be happier
21:12:58  <andythenorth> FooBar: that would be fine
21:13:18  <FooBar> ok, then removing the i_ is perfectly fine with me :)
21:13:25  <andythenorth> Ammler: http://pastebin.com/LSiz1pEF
21:14:06  <Ammler> andythenorth: hg pull?
21:14:25  <andythenorth> no changes
21:14:34  <andythenorth> I pulled already, that's what I'm trying to merge
21:14:41  <Ammler> hmm, what are you trying to do, btw.?
21:14:43  <FooBar> anyways, I'm off to bed now
21:14:46  <FooBar> good night!
21:14:49  <andythenorth> bye
21:14:56  <andythenorth> Ammler: commit outstanding changes, then push
21:15:18  <andythenorth> I guess my repo is screwed again?
21:15:19  <Ammler> so you did again not pull before commit?
21:15:29  <andythenorth> n
21:15:31  *** FooBar has quit IRC
21:15:35  <Ammler> how many commits?
21:15:39  <Brot6> FIRS Industry Replacement Set - Feature #1261 (New): Remove i_ prefix from industry templates, mo... (andythenorth) @ http://dev.openttdcoop.org/issues/1261
21:15:40  <andythenorth> but I saw there were changes, so I rolled back the commit
21:15:45  <andythenorth> one commit
21:15:47  <andythenorth> rolled back
21:16:08  <Ammler> then hg pull and hg up?
21:16:16  <Ammler> maybe you forgot the up?
21:16:19  <andythenorth> no changes
21:16:30  <planetmaker> andythenorth, try hg up -rXXX
21:16:37  <planetmaker> where XXX is the rev you want to update to
21:16:52  <planetmaker> maybe hg up -rtip
21:16:53  <Ammler> isn't that tip?
21:17:30  <andythenorth> hg up -r1205 shows 'unkown revision'
21:17:36  <andythenorth> hg up -rtip shows no changes
21:17:57  <andythenorth> hg tip shows 1205 as tip
21:17:59  * andythenorth confused 
21:18:10  <planetmaker> hg heads?
21:18:11  <andythenorth> how can 1205 be tip and be an unknown revision
21:18:14  <andythenorth> http://pastebin.com/LSiz1pEF
21:18:47  <planetmaker> hg parent?
21:19:00  <andythenorth> 1204
21:19:26  <planetmaker> and hg ci doesn't work?
21:20:22  <planetmaker> actually... what's what you try to do?
21:20:38  <andythenorth> I have one change I want to commit
21:20:52  <andythenorth> maybe I'll just delete and clone again
21:21:17  <andythenorth> I don't know how I broke it this time, I didn't do anything unusual / risky
21:21:43  <Brot6> OpenGFX - Bug #657: Enable company colours for sweets factory (planetmaker) @ http://dev.openttdcoop.org/issues/657#change-3236
21:23:46  <planetmaker> and you get that message when you want to commit the stuff?
21:24:22  <andythenorth> gah
21:24:26  <Ammler> andythenorth: what hg version you use?
21:24:30  <Ammler> hg --version
21:24:31  <andythenorth> my new clone can't push
21:24:36  <andythenorth> how do I authorise it?
21:25:13  <Ammler> add default-push=https://andy...:pw@push.openttdcoop.org/firs to your .hg/hgrc
21:26:14  <andythenorth> Ammler: authorisation failed
21:26:19  <andythenorth> do I need to clone with ssh not http?
21:26:41  <Ammler> well, ssh is old-style :-)
21:26:51  <planetmaker> bb 15 minutes
21:26:52  <Ammler> you can also add the ssh url to default-push
21:27:08  <Ammler> if you clone with ssh, also push will work
21:27:21  <Ammler> but I use http to pull and https to push
21:27:59  <andythenorth> Ammler: resolved that
21:28:05  <Ammler> http://dev.openttdcoop.org/projects/home/wiki/Mercurial
21:28:19  <Brot6> FIRS Industry Replacement Set - Revision 1205:47c66a002554: Feature: additional layout for Forest (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/47c66a002554
21:28:46  <Ammler> andythenorth: still, which version you use?
21:28:53  <andythenorth> 1.2.1
21:29:01  <Ammler> that is stoneaged
21:29:08  <Ammler> we are at 1.6.x now
21:29:31  <Ammler> macport should have newer version
21:30:08  <andythenorth> running it now
21:39:18  <Brot6> OpenGFX - Revision 486:5ca0eeb034f1: Feature #840: Born Acorns uk signals (Ammler) @ http://dev.openttdcoop.org/projects/opengfx/repository/revisions/5ca0eeb034f1
21:41:44  *** frosch123 has quit IRC
21:52:19  *** GT has joined #openttdcoop.devzone
21:54:44  <Brot6> OpenGFX - Revision 487:1a36bea3ed6a: Change: move the toyland signals nfo to a sep. file and incl... (Ammler) @ http://dev.openttdcoop.org/projects/opengfx/repository/revisions/1a36bea3ed6a
21:58:57  <Brot6> OpenGFX - Feature #840 (Closed): Improved signal sprites (Ammler) @ http://dev.openttdcoop.org/issues/840#change-3237
22:05:47  <GT> Now NML is progressing nicely, but I did not follow it in great detail, what would it take to convert the 32bpp-extra project to NML?
22:07:10  <Ammler> Hello GT :-)
22:07:22  *** Seberoth has quit IRC
22:07:25  <Brot6> OpenGFX - Revision 488:a2739bb6b899: Cleanup: those specs are outdated, find up2date specs in .de... (Ammler) @ http://dev.openttdcoop.org/projects/opengfx/repository/revisions/a2739bb6b899
22:07:28  <GT> HI Ammler
22:08:36  <Ammler> you should request 32bpp support from nml :-)
22:08:45  <Ammler> so it does encode the pngs
22:09:21  <GT> True, but currently it uses 8bpp pcxs, first step would be to convert it to nml, or not?
22:10:20  <Ammler> well, that should be possible, but is it worth?
22:10:51  <Ammler> I mean, that grf is quite static, isn't?
22:10:57  <GT> yes
22:12:36  <Ammler> the question is more, is it worth to update the grf with newer graphics and code from opengfx?
22:13:38  <Ammler> and maybe you noticed that we splitted the nfos heavily in the meantime
22:14:15  <Ammler> it might be worth to make the 32bpp extra a branch instead a sep repo?
22:14:15  <GT> not sure, I dont like to provide 8bpp pcx, and coding the offsets etc, just to get them replaced by 32bpp pngs
22:14:41  <GT> splitting up is a good idea I think, anyway
22:14:47  <Ammler> yeah, you shouldn't
22:14:58  <Ammler> or I wouldn't either :-)
22:15:05  <GT> a branch of what?
22:15:11  <Ammler> of opengfx
22:15:29  <Ammler> which would use the needed nfo and pcx from there as #include
22:15:53  * Rubidium wonders whether he proposed an extension to nml that would take the 32bpp sprites and renumber them correctly, get them their correct offsets and then convert the "normal" zoom version (possibly created by scaling) into an 8bpp sprite for the .grf
22:16:28  <Ammler> he, also a good idea :-)
22:17:40  <Ammler> well, the 8bpp images are for those sprites, which miss a 32bpp variant
22:18:48  <Rubidium> Ammler: so it works somewhat transparently; define an 8 bits sprite and it only adds it to the grf, define a 32bpp sprite and it does the renumber/pngcodec magic + downscaling for the grf
22:19:45  <GT> wouldnt the renumbering of the 32bpp sprites need an already renumberd nfo?
22:20:09  <Ammler> Rubidium: or give the possiblity to define 8bpp and 32bpp sprites
22:20:20  <GT> Though the idea sounds great
22:20:42  <Ammler> GT, now you use some unportable .bat files
22:20:53  <Ammler> wouldn't nml or nfo be better
22:20:58  <GT> what is .bat?
22:21:16  <Ammler> those batch scripts Ben uses for his sprites
22:21:22  <Ammler> to encode the pngs
22:21:46  <Ammler> that is imo like a nfo
22:22:21  <GT> I know, Im more used to shell scripts, and yeah nml would be much better, esp when I dont have to determine offsets or size of 8bpp pcxs
22:22:24  <Ammler> just not portable and specified
22:22:49  *** Seberoth has joined #openttdcoop.devzone
22:23:16  <GT> just wondered the work flow, if specing pngs in nml/nfo would work, that would be best
22:23:19  <planetmaker> [00:15]	* Rubidium	wonders whether he proposed an extension to nml that would take the 32bpp sprites and renumber them correctly, get them their correct offsets and then convert the "normal" zoom version (possibly created by scaling) into an 8bpp sprite for the .grf <-- it sounds familiar. But it's probably not in the bug tracker ;-)
22:23:33  <Ammler> also a nfo real sprite could be extended for example add the png at end after the offsets
22:23:41  <Rubidium> planetmaker: ofcourse not, it's on the forum
22:23:48  <planetmaker> :-)
22:24:32  <planetmaker> just wondered the work flow, if specing pngs in nml/nfo would work, that would be best <-- NML reads pngs
22:24:51  <Ammler> :-)
22:25:03  <Ammler> but opengfx devs aren't allowed to use it :-P
22:25:07  <planetmaker> it has yet no conversion. But it doesn't need that really
22:25:22  <planetmaker> Ammler: you are. But _source_ of opengfx is still nfo and pcx
22:25:28  <Ammler> :-)
22:25:53  <planetmaker> when there's a first release of NML, I'll happily add NML support
22:26:01  <Ammler> anyway, did you review the signals?
22:26:09  <planetmaker> It's already 80% done anyway
22:26:12  <Ammler> is that ok that way?
22:26:18  <planetmaker> I didn't yet look
22:27:52  <Ammler> I wonder, if 2006TTD will make the templated files
22:28:07  <Ammler> else I will do that too, it isn't that much
22:30:14  <GT> I wondering if it is possible to start with an nml file referring to png, pngcodec the pngs, and then convert to 8bpp and create the nfo. Probable the biggest hurdle is the determination of the offsets, since they are different for ground tiles and vehicles
22:30:30  <planetmaker> well, yes, Ammler :-)
22:30:35  <GT> s/I wondering/ I was wandering/
22:30:38  <planetmaker> looks fine to me
22:30:53  <GT> s/wandering/wondering
22:31:00  <planetmaker> :-D
22:31:33  <Ammler> GT: finding the right colors isn't that easy
22:31:37  <planetmaker> GT: it certainly is possible. But offsets will need adjustment in any case, I guess
22:31:52  <planetmaker> and colours will be interesting to get right. But not impossible, I say
22:32:00  <Ammler> gimp does that quite good, I am not sure, how well python-imging would do that
22:32:15  <GT> yes, vehicles using some kind of centre of gravity and ground tiles the top centre as reference point
22:32:47  <GT> which makes it difficult to automate, though nml may have knowledge about the method to use
22:33:17  <planetmaker> nml is not more intelligent with sprite alignment than NFO.
22:33:23  <planetmaker> it's all manual work
22:33:23  <Ammler> planetmaker: if you have the same sprite in 32bpp and 8bpp, the offsets are the same
22:33:34  <Ammler> or am I wrong?
22:33:36  <planetmaker> you just may use mathematical formula for the positions
22:33:42  <GT> colors are probably difficult, 32bpp->palette isnt straightforward, the other way is easier
22:33:52  <planetmaker> but if the size is the same. Then the same alignment should be good
22:34:05  <planetmaker> I thought about re-scaling
22:34:08  <Ammler> GT: we used some 32bpp sprites in opengfx
22:34:14  <Ammler> you find those quite well :-)
22:34:16  <planetmaker> If no re-scaling, then no offset change. I recon
22:34:19  <Ammler> easy*
22:34:56  <Ammler> like the artic hotel or the tropic church
22:35:00  <GT> correct, but when I start with 32bpp pngs, the offset would be different for vehicles or ground, when the sprite has the same dimension
22:35:12  <planetmaker> hu?
22:35:28  <planetmaker> Well. Something you cannot do, is automatic alignment
22:35:36  <planetmaker> You have to align each sprite separately
22:35:43  <planetmaker> The only exception is really ground tiles
22:35:57  <Ammler> GT: the offset is different because your sprite has other sizes?
22:36:02  <planetmaker> One can come up with formula for house sprites and one-tile width
22:36:17  <planetmaker> But other than that: manual work until it looks right
22:36:30  <Ammler> nah, everything is somehow logical
22:36:37  <planetmaker> though there are ways to put that into formula, it's tedious
22:36:42  <Ammler> e.g. I have same offset for every signal
22:36:49  <planetmaker> yes, of course
22:37:06  <planetmaker> But only if all sprites are the same size.
22:37:17  <planetmaker> If different signals have different widths, the offsets are not the same
22:37:22  <GT> Ammler, no, because ground tiles and vehicle sprites are handled differently, so I guess we would have to specify the offset manually in any case, the size of the sprite can be determined automagically for png
22:37:23  <Ammler> yep
22:37:48  <Ammler> GT but the sizes/offsets are the same in 32bpp and 8bpp
22:37:54  <Ammler> you need to adjust only one
22:37:58  <Ammler> would*
22:38:33  <GT> that would be the offset, like I said the size can be determined from the png
22:39:08  <Ammler> how do you "code" the png now?
22:39:11  <GT> so nml input would have to be the png file name, and the offset
22:39:17  <Ammler> be looking ingmae?
22:39:46  <Ammler> and the pcx
22:40:02  <Ammler> and possibly the additional zoom level pngs
22:40:17  <Ammler> s/pcx/8bpp-png/
22:40:24  <GT> with png_codec, for ground tiles you can do a best first guess, depending on the height and width of the sprite and refine that in game, for vehicles too, but then the formula is different
22:42:44  <Ammler>  1238 sprites/pcx/house.png 146 6584 01 21 4 -1 -19 sprites/32bpp/house.png [sprites/32bpp/house_z1.png...]
22:43:03  <Ammler> how a nfo line could look?
22:44:34  <GT> so start with nml, offset and (pngcodeced)symbolic png file name -> create nfo for pcx ->renumber pngs  + create 8bpp pcx
22:44:56  <Ammler> no, no need for pngcodec
22:45:14  <Ammler> that would be done by nfml
22:45:15  <Ammler> nml
22:46:08  <Ammler> there is no pcx in nml
22:46:13  <GT> no, I mean the grf creator would have to provide pngcodeced pngs, he would have to test it ingame anyway and nml could use the offset
22:46:14  <Ammler> already
22:46:31  <GT> There is no pcx?
22:46:39  <planetmaker> nml can read png natively
22:46:44  <planetmaker> swedish rails has no pcx
22:46:45  <Ammler> nml creates grf from png
22:47:13  <planetmaker> (or any other paletted image format readable by the python image library)
22:47:23  <GT> really? didnt know that, and liking it better by the minute
22:47:54  <planetmaker> but it needs the correct palette.
22:48:01  <Ammler> GT, why using pngencoded pngs?
22:48:13  <Ammler> why not let nml encode it
22:48:20  <GT> you cant test pngs without pngcodecing it
22:48:30  <Ammler> test?
22:48:51  <GT> when creating the png
22:48:59  <GT> and want to see it ingame
22:49:01  <Ammler> yes, that guy should use nml
22:49:26  <Ammler> to make a tar which he can load
22:49:37  <Ammler> easier as making a batch file or whatever
22:50:03  <GT> that would be really nice, but how would nml (interpreter) determine the correct offset?
22:50:17  <Ammler> you need to define that in the nml
22:50:25  <Ammler> like you do that in the .bat now
22:50:33  <Ammler> or in your .sh
22:50:44  <Ammler> or whatevery ou use to encode it now
22:50:48  <GT> right, and how would you do that? by testing it ingame, which would require pngcodecing
22:51:34  <GT> that's how it is done now, pngcodec the png, test ingame, adapt the bat/sh and try again
22:51:35  <Ammler> well, you would need to talk with the nml devs
22:51:46  <Yexo> GT: I think what Ammler means is that instead of just providing a 8bit pcx/png file in the nml source you also specify a 32bpp png file, nml then remanes the file to the correct number and pngcodecs it
22:51:55  <Yexo> that's not possible currently, but that could be implemented
22:52:12  <Ammler> ah, yes, of course
22:52:22  <Ammler> I meant that as a feature request to nml :-)
22:52:49  <Yexo> and imo if we go that way we should leave the "1 sprite per 32bpp png file" approach
22:53:09  <Yexo> of course it's still needed for the output, but there is no reason nml can't use one big png file as input and make the smaller files itself
22:53:10  <Ammler> Yexo: does that matter?
22:53:24  <Yexo> no, it probably makes it easier for the artists
22:53:28  <GT> Yexo, I understood, but I wondered how the png creator would specify the offset in nml without pngcodecing it himself when creating
22:53:31  <Ammler> I mean, I would already do that with 8bpp
22:53:52  <Yexo> GT: exactly the same as for 8bpp sprites
22:54:18  <Ammler> and exactly like he does that with his .batch or shell skript or whatever he uses
22:55:19  *** Seberoth has quit IRC
22:56:11  <Yexo> http://pastebin.ca/1919061 it could for example work like this
22:56:47  <Yexo> here I'm assuming that the 32bpp file has exactly the same layout/sprite sizes as the default 8bpp sprites
22:57:05  <Yexo> if they do a template would make things even easier
22:57:18  *** ODM has quit IRC
22:57:56  <Ammler> is it a requirement to have all sprites in one file in nml?
22:58:09  <Yexo> no, you can use as many differnt files as you want
22:58:12  <GT> ok, so the workflow would be: create an nml with a best guess offset, and provide an uncoded png, then start the nml interpreter that creates a renumbered pngcodeced png and a grf file test that ingame
22:58:39  <Ammler> or just a tar
22:58:52  <GT> and adapt the offsets when necessary, while nml creates the 8bpp pcxs during the process
22:59:27  <Yexo> nml never creates 8bpp pcx files, it just writes the grf with the 8bpp sprites in it and some png files
22:59:27  <Ammler> nml does write the grf directly, no need for pcx :-)
22:59:31  <GT> taring is only needed when the set is complete imo, no need to do that during testing
22:59:46  <Yexo> nml should never create the tar, just a proper directory structure
22:59:52  <Yexo> the makefile can then tar it if you want that
22:59:57  <Yexo> or whatever else you use
23:00:03  <GT> but can openttd handle grfs with pngs?
23:00:26  <Yexo> GT: in a grf each sprite is just an array of bytes
23:00:33  <Yexo> it doesn't matter what the original source was
23:01:09  <Ammler> that is what grfcodec makes it to, today it would make a png
23:01:13  <Yexo> in theory I could code nml to read a 32bpp png, convert each pixel to the closest color that is in the palette and write that to the grf file
23:01:16  <GT> ok, but that would need changes to the openttd code, i think it assumes pcx now?
23:01:38  <planetmaker> GT: no ;-)
23:01:40  <Ammler> NO
23:01:43  <planetmaker> it assumes grf format
23:01:46  <planetmaker> which is neither
23:01:52  <Yexo> openttd assumes grf format, which is neither pcx nor png
23:01:59  <planetmaker> :-)
23:02:02  <Ammler> pcx is made with grfcodec from grf
23:02:42  <Yexo> the image format of sprites in the grf is just size and then for each pixel an offset in the color palette
23:03:03  <Yexo> the palette itself is not stored in the grf file (unlike in pcx/png files)
23:05:24  <GT> Ok, I'll rephrase, palette is an 8bpp concept, openttd does not handle 32bpp graphics by default, it assumes 8bpp graphics in the grf?
23:05:36  <Yexo> yes
23:05:43  <Yexo> and I never proposed to change that
23:06:24  <GT> so if i provide a 32bpp png to nml, it would have to be converted to an 8bpp format
23:06:33  <Ammler> why?
23:06:47  <Yexo> if you only provide a 32bpp png and no 8bpp default then yes, it'd have to be converted
23:07:16  <Ammler> it would renumber to the sprite defined in the nml and then saved in the "32bppfolder" like now
23:07:20  <Yexo> I think it's better if you would always have to provide both an 8bpp png and a 32bpp replacement, so nml can use the 8bpp for writing the grf
23:07:29  <Ammler> and pngencoded
23:07:46  <Yexo> Ammler: because nml has to write the grf, if you only have a 32bpp file as input you have to convert it :)
23:08:23  <Ammler> Yexo: or you could use a dummy transparent sprite
23:08:29  <Ammler> or whatever
23:08:52  <Yexo> of course there are multiple options in that case :)
23:09:01  <GT> So were back at what I said before, providing a 32bpp pngcodeced png and an nml file would be enough to create the rest
23:09:25  <Ammler> _not_ encoded
23:09:28  <Ammler> that is part of nml
23:09:37  <Yexo> the 32bpp input file doesn't have to be pngcodeced yet
23:09:41  <Yexo> that part can easily done by nml
23:09:48  <Ammler> it should, (imo)
23:10:03  <GT> only if i provide an 8bpp graphic too
23:10:23  <Yexo> that has nothing to do with it
23:11:18  <GT> maybe im wrong, but if i provide an uncoded png and an nml file, how would the nml interpreter generate the offsets?
23:11:30  <Ammler> you have those in the nml
23:11:41  <Ammler> check the example paste
23:12:00  <Ammler> xpos, ypos, compress, XOFF, YOFF
23:12:02  <GT> and how would i know what to put in the nml file, when I cant test
23:12:09  <Ammler> might be other order...
23:12:23  <Ammler> how do you do it now?
23:12:33  <Ammler> how you know, what to give the pngcodec?
23:12:34  <Yexo> GT: how do you know how to pngencode a sprite when you can't test it before you have pngcodec it? (situation currently)
23:12:35  <GT> pngcodec and test
23:12:42  <Yexo> answer: you make an educated guess and test the result
23:12:59  <Ammler> pngcodec doesn't need offsets?
23:13:03  <Yexo> of course it does
23:13:13  <GT> it only needs offsets, no sizes
23:13:17  <Ammler> well, you can always start with 0 :-)
23:13:40  <Yexo> that is because pngcodec assumes the complete png file is 1 single sprite
23:13:46  <Yexo> so the size is the size of the png file
23:14:00  <Ammler> python-imaging not able to?
23:14:23  <Ammler> well, not sure, what is easier
23:14:41  <Ammler> crop pngs or define sprite sizes
23:14:42  <Yexo> there is no technical reason every sprite as input for nml should be in a differnt file, you can have multiple sprites in one 32bpp png and nml can split them to multiple output files for you
23:14:50  <GT> ok, summarize, provide an uncoded png, and do the educated guess for offset in nml, and nml generates the grf and pngcodeced renumbered pngs
23:14:58  <Yexo> yes
23:15:45  <Yexo> the advantage of having one file with multiple sprites is that you can take the 8bpp graphic file as example and just replace all sprites, taking care to keep the exact same sizes for all sprites, if you do that the same offsets should work
23:15:49  <GT> and the grf contains the 8bpp data as well for those blitters? Im starting to drewl
23:16:00  <Ammler> Yexo: but nml would need to crop the input png to single pngs for openttd
23:16:11  <Ammler> (I assume)
23:16:21  <Yexo> Ammler: yes, but it already needs to do that for the 8bpp input
23:16:48  <planetmaker> hm... ugly commit to fix the maglev track sprites?
23:16:58  <Ammler> why?
23:17:32  <Yexo> GT: I'm not completely up to date on the differences between trunk and EZ in the 32bpp png input
23:18:13  <planetmaker> Ammler: ugly as in just replace the wrong sprites in the HUGE pcx files
23:18:21  <planetmaker> which is actually TWO huge pcx files
23:18:27  <planetmaker> for no good reason I see
23:18:28  <Ammler> no pcx editing
23:18:40  <Ammler> add a new file with those sprites
23:18:43  <planetmaker> :-)
23:19:15  <planetmaker> that doesn't make sense in this case either as it's only single track sprites out of context
23:19:18  <Ammler> I also have added a 1sprite pcx
23:20:12  <planetmaker> having one set of tracks in one file makes sense
23:20:36  <Ammler> e.g. http://dev.openttdcoop.org/projects/opengfx/repository/changes/sprites/pcx/gui/graphs.pcx
23:20:37  <planetmaker> but that means... heavy cutting, editing, re-alignment :-(
23:20:47  <planetmaker> yes
23:20:57  <Ammler> or 2 sprites: http://dev.openttdcoop.org/projects/opengfx/repository/changes/sprites/pcx/gui/savemenu.pcx
23:21:00  <planetmaker> But the GUI sprites are independent of eachother somewhat
23:21:10  <planetmaker> the track sprites not really
23:21:30  <Ammler> then copy the whole track sprites out there
23:21:50  <planetmaker> that's the clean solution, yes
23:22:04  <planetmaker> But then not before sleeping anymore
23:22:08  <Ammler> you can keep the size of the pcx
23:22:25  <Ammler> just replace the whole rest with pure white
23:22:33  <planetmaker> No... it's the infra0X pcx
23:22:35  <Ammler> so you don't need to edit the offsets
23:22:51  <Ammler> I meant the positions
23:22:54  <planetmaker> they're thousands of pixels
23:23:03  <planetmaker> in the y-dimension
23:23:19  <Ammler> well, you can simply calculate that
23:23:24  <Ammler> and keep xpos
23:23:35  <planetmaker> yeah, I guess
23:23:38  <planetmaker> later :-)
23:23:55  <Ammler> anyway better make a copy as replace the exisiting
23:23:58  <planetmaker> it's quite a bit work for all sprites and climates
23:24:06  <planetmaker> hu?
23:24:15  <planetmaker> why?
23:24:19  <Ammler> a copy of infra.pcx
23:25:21  <planetmaker> why is it better to add another big file?
23:25:32  <Ammler> to keep history at least
23:25:44  <GT> Yexo: 32bpp EZ sprite format is exactly the same, only difference is the naming convention: a postfix _z0 or _z1 is used for the filenames, and there could be a off by 1 or 2 pixels when the png creator does not create a png size that is divisible by 4 (or pngcodec it with an offset that is not divisibable by 4)
23:25:49  <planetmaker> history of pcx is kept...
23:25:51  <Ammler> not everyone is able to make a proper diff of a binary
23:26:01  <planetmaker> the repo has it
23:26:20  <Ammler> so I change something in the pcx and you are able to tell me what I have changed?
23:26:48  <Ammler> hmm, I know it is possible
23:26:56  <Ammler> but I wouldn't know how :-)
23:28:03  <planetmaker> it's a hassle, yes
23:28:22  <Ammler> IMO, it is worse to edit a pcx then using nml :-P
23:28:45  <planetmaker> nice. My git diff for that patch is 1.6M ;-)
23:29:13  <planetmaker> and redmine refused to attach it to the issue
23:29:23  <Ammler> he?
23:29:26  <planetmaker> 'request too large'
23:29:30  <Ammler> 5MB is limit, afgaik
23:29:51  <planetmaker> 413 Request Entity Too Large
23:29:53  <planetmaker> nginx/0.7.65
23:29:59  <Ammler> oh
23:30:08  <Ammler> a nginx limit?
23:30:13  <planetmaker> seems like
23:33:42  <planetmaker> but don't worry about that
23:34:51  <planetmaker> bed time now.
23:36:15  <planetmaker> so have also a good night :-)
23:36:34  <Ammler> fixed
23:37:57  <SmatZ> good night, planetmaker :)
23:42:37  <Ammler> good night pm and SmatZ
23:42:41  <Ammler> and rest
23:42:46  <SmatZ> good night, Ammler :) sleep well
23:43:01  <Ammler> thanks, same to you :-)
23:44:54  *** KenjiE20 has quit IRC
23:49:13  *** GT has left #openttdcoop.devzone

Powered by YARRSTE version: svn-trunk