Times are UTC Toggle Colours
00:30:04 *** KenjiE20 has quit IRC 00:52:21 *** Brot6 has quit IRC 10:55:31 *** Webster has joined #openttdcoop.devzone 12:11:15 <Ammler> planetmaker: dev needs to start after bundles so it can mount a share from bundles 12:11:36 <Ammler> the vms start with order of the VMID, dev was 101, bundles 102 12:12:04 <Ammler> now I moved dev to 103 and next time a hard reboot should not hold bundles down 12:13:06 <Ammler> oh, I only changed the internal ip (vmid) 12:13:23 <Ammler> does not effect anything (should not, please report else) 12:14:21 <Ammler> the internal ips are 10.10.<last public ip tuple>.<vmid> 13:43:46 *** Lakie has joined #openttdcoop.devzone 14:13:43 *** ODM has joined #openttdcoop.devzone 15:14:23 <Ammler> hg 1.8.3 seems not working with hg-git, just if you wanna update :-) 15:14:58 <planetmaker> I never used hg-git so far 15:15:15 <planetmaker> But it needs at least 1.7.x (dunno which x) for subrepositories 15:15:22 <Ammler> I used it with cargodist, but it was a pain :-) 15:15:57 <Ammler> our server is on 1.8.2 afaik 15:16:05 <planetmaker> I use git directly for that, and for yacd as well (and ufoAI ;-) ) 15:16:33 <Ammler> btw. there is git.openttdcoop.org 15:16:41 <planetmaker> ach? What for? 15:16:47 <Ammler> :-D 15:17:00 <Ammler> I played around with it 15:17:15 <Ammler> there is also svn on the devzone 15:22:50 <Ammler> planetmaker: btw. did you try to ssh to the server this morning before the reboot? 15:24:31 <planetmaker> hm, I think not everyone 15:24:48 <Ammler> everyone? 15:25:08 <planetmaker> bundles, dev, bouncer, games were all not doing their service 15:25:14 <Ammler> but not hypervisor? 15:25:19 <Ammler> haydn.openttdcoop.org 15:25:22 <planetmaker> that responded to ping 15:25:51 <Ammler> yep, that is the only one, which responds to ping 15:25:53 <planetmaker> I had not much time, thus I chose the quick solution 15:26:10 <planetmaker> as I knew the machines would then boot up ;-) 15:26:18 <Ammler> I never made iptables to forward pings to the mvs 15:26:55 <Ammler> it is quite silly, /var/log/messages starts at 6.25 UTC 15:27:26 <planetmaker> 8:30... might be the time of reboot 15:27:38 <Ammler> hmm, so where is the log from before? 15:27:43 <Ammler> very strange 15:27:47 <planetmaker> 8:30 CEST 15:27:50 <planetmaker> = 6:30 UTC 15:27:52 <Ammler> yes 15:28:13 <Ammler> I just see logs from the reboot 15:29:01 <Ammler> well, maybe better, I might not have a clue why you needed to reboot anyway :-) 15:29:22 <planetmaker> better certainly not :S 15:30:28 <Ammler> well :-d 15:31:08 <Ammler> yeah, bad that I didn't change the boot order before you run the reset 15:31:18 <Ammler> else nobody would have noticed 15:31:37 <planetmaker> well... all people who use the bouncer ;-) 15:31:37 <Ammler> well, except you 15:31:49 <Ammler> not that early on the morning ;-) 15:31:50 <planetmaker> t3rken was awake the same time as me 15:35:56 <Ammler> maybe I should checkout www.zabbix.com 15:38:10 <Brot6> NewGRF Meta Language - Feature Request #2577 (New): autoconvert palette if possible (planetmaker) @ http://dev.openttdcoop.org/issues/2577 15:40:24 <Ammler> planetmaker: are you sure, you want that? 15:40:53 <planetmaker> Ammler, if I have image files in dos and windows palette, yes, I want then nml to automatically convert the windows palette sprites 15:40:57 <Ammler> I mean, then the image author does not have a reason to fix the image and will continue to use it 15:40:58 <planetmaker> not the files 15:41:12 <planetmaker> And yes, I definitely want that, Ammler 15:41:23 <planetmaker> Or I cannot ever unify OpenGFX with the OpenGFX+ newgrfs 15:41:34 <planetmaker> or only when OpenGFX uses the dos palette 15:42:45 <Ammler> I wonder, how you know, which palette is used, when you open it in gimp? 15:42:58 <planetmaker> test-convert 15:43:15 <planetmaker> or, if you know the palette, look at it 15:43:25 <planetmaker> It's one of the dialogues which you can have open permanently 15:43:57 <Ammler> hmm 15:44:12 <Ammler> true 15:46:08 <Ammler> you could setup opengfx as subrepo of ogfx+ newgrf 15:46:27 <planetmaker> my idea is to have all graphics in a common sub repo 15:46:46 <Ammler> you mean something like a opengfx-media 15:46:49 <planetmaker> thus the projects remain destinct. But all use the opengfx-gfx sub repo 15:47:25 <planetmaker> and currently I have opengfx-terrain (win) and opengfx-terrain (dos) for opengfx and opengfx+landscape respectively 15:47:29 <planetmaker> quite stupid ;-) 15:47:38 <planetmaker> and nasty double work 15:47:38 <Ammler> true 15:47:54 <planetmaker> with many errors which I can do again and again on conversion 15:48:08 <Ammler> well, why do you already work with dos there? 15:48:17 <planetmaker> yes 15:48:25 <Ammler> I mean converting to dos i quite easy everytime later 15:48:39 <planetmaker> opengfx+landscape was dos since the beginning thereof 15:48:42 <Ammler> so you could also simply use windows until we can convert opengfx 15:49:15 <Ammler> every ogfx+ project is dos? 15:49:26 <planetmaker> not sure currently, but I don't think so 15:49:47 <planetmaker> Well. I might convert OpenGFX+landscape (back) to windows. But... that's stupid, too 15:49:58 <Ammler> well, I told you guys what to do so we could convert opengfx to dos :-P 15:50:10 <Ammler> but as always you don't like my suggestions 15:50:48 <Yexo> was that really rejected or just never implemented? 15:51:12 <planetmaker> I think Rubidium had some objects to interpret "no palette declared" as "uses windows palette". 15:51:21 <Yexo> assuming you talk about using the win palette as default for newgrfs that don't specify a palette, instead of using the palette of the base graphics like currently 15:51:28 <planetmaker> But I might err :-) But I think it's sensible 15:51:31 <Ammler> Yexo: newgrfs without a14 = default palette windows instead base set 15:51:38 <planetmaker> sensible to have windows palette assumed as default 15:52:15 <Ammler> as there is no bananas grf with dos 15:52:17 <Yexo> if the problem is the original dos graphics a new parameter could be added to basesets 15:52:25 <planetmaker> Ammler, there is... OpenGFX+Landscape ;-) 15:52:32 <Ammler> no, that has a14 15:52:40 <planetmaker> yes 15:53:28 <planetmaker> Yexo, what kind of parameter? 15:53:40 <Yexo> default_palette_for_newgrfs 15:53:42 <Ammler> a14 don't matter in that case, we can't convert opengfx because of the other newgrfs 15:53:56 <planetmaker> Yexo, not rather a parameter for base sets, but it should be an adv. setting 15:54:41 <Yexo> making it an advanced setting is useless, as the problem is the default behavior 15:54:45 <planetmaker> which... might be actually the way to go. Just a cfg entry (w/o interface would suffice) to define the default assumed palette 15:54:48 <Yexo> we already have a toggle palette button in the newgrf window 15:54:54 <Ammler> it would also be better for those people which actually use a dos paletted base set 15:55:08 <planetmaker> Yexo, yes, but then the default behaviour would be defined by the setting 15:55:24 <Yexo> would the be a single person who changes that setting? 15:55:31 <Ammler> they need to change the palette for every bananas grf or the start parameter 15:55:38 <planetmaker> Nope. All would set it to "assume windows paletted newgrf" 15:55:50 <Yexo> so why have the setting at all if nobody changes it? 15:55:54 <planetmaker> :-) 15:56:09 <Ammler> Yexo: ask Rubidium :-) 15:56:09 <planetmaker> I don't need a setting. But I don't see a need for a base set change 15:56:10 <Yexo> <planetmaker> I think Rubidium had some objects to interpret "no palette declared" as "uses windows palette". <- do you have any such objections, Rubidium? 15:56:14 <planetmaker> It's got nothing to do with base sets 15:57:02 <Ammler> well, I once suggested to rename the palette from windows to reduced and dos to full 15:57:14 <planetmaker> that's different ;-) 15:57:34 <Ammler> you think, it's not the word "windows"? 15:57:51 <Brot6> OpenGFX+ Industries - Bug #2561 (Closed): Cargo payment rates (Terkhen) @ http://dev.openttdcoop.org/issues/2561#change-6653 15:57:55 <planetmaker> they're stupid. But established. And found everywhere in the documentation 15:58:24 <Ammler> does not mean it is bad to rename 15:58:31 <Ammler> we once renamed patches to adv. settings 15:58:47 <Ammler> was also a long way 15:58:56 <planetmaker> yes 15:58:58 <Yexo> yes, but that was mainly to avoid confusion between source code patches and settings 15:59:17 <Ammler> yep, and renaming the palette would avoid confusing between os and palette 15:59:18 <planetmaker> well, it's also the better name (now) 15:59:53 <planetmaker> it could be cautiously renamed ingame like dos (full) and windows (limited) 16:00:33 <Ammler> some time it was also associated openttd=windows 16:02:21 <Brot6> OpenGFX+ Industries - Bug #2578 (New): Power plants can close even if serviced (Terkhen) @ http://dev.openttdcoop.org/issues/2578 16:03:02 <Ammler> anyway, try to find a bad situation, if you have openttd using windows for every non a14 newgrf 16:03:29 <Yexo> Ammler: both me and planetmaker have already said we think that's a good idea 16:03:35 <Yexo> you don't have to convince us 16:04:13 <Ammler> ok, nice :-) 16:14:44 <Brot6> NewGRF Meta Language - Feature Request #2577: autoconvert palette if possible (yexo) @ http://dev.openttdcoop.org/issues/2577#change-6654 16:15:52 <planetmaker> Sweet, I'll test that late(r) tonight. I've at home a repo already prepared which uses both 16:16:11 <Yexo> great :) 16:16:20 *** frosch123 has joined #openttdcoop.devzone 16:16:33 <planetmaker> but I'll not be home before ~22:30 16:17:55 <Yexo> don't rush yourself, the issue has been around for quite a while, I'm in no hurry to implement it very quickly now 16:18:12 <planetmaker> :-) 16:18:45 <Ammler> planetmaker: did you already work with subrepos? 16:19:22 <Ammler> would it need changes on the building side? 16:19:38 <planetmaker> Ammler, not much. But I (locally) setup opengfx and some friends as sub repos to test its feasibility 16:20:08 <planetmaker> I think it won't need adjustment on the cf's side 16:20:28 <planetmaker> but that'll need a bit more testing. I'll first clone all that as test projects to the CF and then we can see 16:21:44 <Ammler> well, basically there would be one new repo 16:21:53 <Ammler> for the images 16:21:57 <planetmaker> yes 16:22:04 <Ammler> and the current project would use that as subproject 16:22:07 <planetmaker> yes 16:22:30 <Ammler> hmm, same could be done with the makefile_framework maybe :-) 16:22:40 <planetmaker> hm... that's an idea 16:22:45 <planetmaker> a good one actually 16:23:12 <planetmaker> though... well... not sure 16:23:24 <planetmaker> the framework's repo is much more than one project needs 16:24:04 <planetmaker> hm... maybe if the framework has two subrepos, one for nml, one for nfo, those could be included 16:24:47 <planetmaker> I shall definitely consider that. It will need a bit thinking on the framework's dir layout, but yes 16:25:07 <planetmaker> I'd like that, too :-) 16:25:16 <planetmaker> Would make updating easier as well 16:26:08 <Ammler> you would mainly store the revision of the makefile_framework in Makefile.config 16:26:18 <Ammler> or something like that 16:26:30 <planetmaker> Ammler, that's not needed 16:26:40 <planetmaker> A repo does not automatically update it's sub repo 16:26:43 <planetmaker> You have to ask for it 16:26:44 <Ammler> is that stored in the .sub? 16:26:49 <planetmaker> in .hgsub 16:27:05 <Ammler> yep, meant that, not worked with it yet :-) 16:27:26 <Ammler> also .hgsub would allow svn 16:27:33 <planetmaker> hg pull -u updates your repo to head and the subrepo to the revision which was used with head when it was checked in 16:27:37 <planetmaker> yes. and git 16:27:42 <Ammler> so we could include extra_grf from openttd 16:27:49 <planetmaker> why? 16:27:59 <Ammler> for the gui things we share 16:28:04 <Ammler> e.g. 16:34:13 <Ammler> subrepos aren't part of the repo, so they don't hurt 16:34:26 <Ammler> or am I wrong? 16:34:42 <planetmaker> Well, you'll need it locally for each 16:34:50 <planetmaker> as far as I saw it 16:34:58 <planetmaker> and the amount shared there is minimal 16:37:24 <Yexo> Ammler: extra_grf is no longer a separate repo, it's part of trunk 16:38:12 <Ammler> Yexo: doesn't matter, svn is quite easy to extract a subdir 16:39:29 <Ammler> actually I have no idea, how I made last GUI update 16:39:49 <planetmaker> still, there's hardly enough sprites shared, Ammler. Maybe airport preview? 16:40:06 <Yexo> not even those, since the airport preview depends on the actual airport sprites 16:40:27 <Yexo> not actually depends, but the airport preview for original base graphics are different than for opengfx 16:40:44 <Ammler> there are only some GUI sprites afaik 16:41:40 <Ammler> like the flags or the collabse window and such 16:42:51 <Ammler> the work to change opengfx to use those sprites sheets might not be worth anyway 16:43:36 <Ammler> it uses one png per category, I made one png per change 16:52:14 <Rubidium> can't you already set the default palette? 16:52:52 <planetmaker> afaik not 16:52:57 <planetmaker> but ... I might err 16:53:29 <Yexo> afaik the default palette is the palette of the base graphics set 16:54:05 <Rubidium> then what does -i do? 16:54:59 <Rubidium> and isn't that, like -I, -S, -M, -v, -s, -m, -b stored (optionally) in the config file? 16:55:50 <Rubidium> and the reason against going for defaulting to windows is because it's simply the lesser quality palette 16:56:39 <Yexo> but the large amount of windows-paletted grfs prevent opengfx from changing to the dos palette 16:57:59 *** Webster has joined #openttdcoop.devzone 16:59:51 <Rubidium> well, for OpenGFX you still have to wait a year if you want to do any real changes to OpenTTD's handling 17:00:27 <planetmaker> we'd not need to change the use of -I and -i for choosing windows as default palette 17:01:50 <Rubidium> well, how many bananas NewGRFs are DOS paletted? 17:02:02 <Yexo> none without action14 17:02:04 <planetmaker> without a14? None 17:02:23 <planetmaker> or at least none I know 17:02:57 * Rubidium wonders how many are using a dos paletted base set + dos paletted NewGRFs 17:03:32 * Rubidium knows at least one matching the first part, but that person rarely plays with NewGRFs. And if he does, he uses savegames from others so the palette is set right 17:03:35 <Yexo> probably almost nobody, since the bulk of the grfs on bananas won't work 17:03:41 <planetmaker> :-) 17:06:05 <Rubidium> did we spec something about the palette if a14 was used but the palette wasn't set? 17:07:06 <Yexo> no 17:07:16 <Yexo> no palette set in a14 == no a14 at all 17:07:22 <Yexo> at least wrt the palette 17:07:34 <Rubidium> bugger... put it on the nfov8 list then ;) 17:07:36 <planetmaker> not in the NewGRF wiki 17:07:50 <planetmaker> Do we have somewhere an nfo v8 list? 17:07:59 * Rubidium decides not to put dinner on that list though 17:08:11 <planetmaker> Or shall I animate the (dead) link in frosch's wiki user profile? 17:08:32 <Yexo> planetmaker: http://devs.openttd.org/~frosch/texts/grf_version8.txt 17:08:48 <planetmaker> ho 17:09:23 <Yexo> it's a bit outdated though, since it still lists a proposal to specify the used palette 17:09:34 <Yexo> and grf versions 17:11:06 <planetmaker> http://wiki.openttd.org/Frosch <-- I thought about that page linked there. More editable 17:11:15 <planetmaker> frosch123, should I transfer the contents? 17:14:23 <frosch123> the plan was to do that, but i never got around :) 17:14:32 <frosch123> feel free to move stuff :) 17:14:41 <planetmaker> ok, I paste it and will edit it slightly to update 17:16:14 <frosch123> maybe we should make bananas reject grfs without a14 palette 17:16:33 <planetmaker> that would stop old NewGRFs being added 17:16:41 <planetmaker> But... maybe, yes 17:17:03 <frosch123> and we can add a gui setting for the default palette to use when adding grfs 17:17:09 <planetmaker> Actually idea: allow adding, but don't allow max_version > OpenTTD 1.0.0 17:17:15 <frosch123> which can then default to win independent of -i and -I 17:17:22 <Brot6> Following repos didn't need a nightlies update: 2cctrainset (r750), 32bpp-extra (r40), ai-admiralai (r75), ai-aroai (r33), ailib-common (r21), ailib-direction (r17), ailib-list (r32), ailib-string (r29), ailib-tile (r16), airportsplus (r73), basecosts (r25), belarusiantowns (r8), bros (r52), chips (r138), comic-houses (r71), firs (r1989), fish (r618), frenchtowns (r6), german-townnames (r33), grfcodec (r828), grfpack (r279), heqs 17:17:22 <Brot6> (r605), indonesiantowns (r41), manindu (r7), metrotrackset (r56), narvs (r37), newgrf_makefile (r285), nml (r1323), nutracks (r186), ogfx-industries (r53), ogfx-landscape (r62), ogfx-rv (r80), ogfx-trains (r239), ogfx-trees (r42), opengfx (r658), openmsx (r97), opensfx (r97), smts (r19), snowlinemod (r49), spanishtowns (r10), swedishrails (r202), swisstowns (r22), transrapidtrackset (r15), ttdviewer (r31), ttrs (r36), worldairlinersset 17:17:24 <Brot6> (r671) 17:17:35 <frosch123> planetmaker: tmwftlb 17:18:15 <frosch123> i would rather consider updating the grfid tool to also check win palette 17:18:47 <frosch123> s/win/a14/ 17:19:01 <planetmaker> hm? 17:19:12 <frosch123> e.g. turning "grfid" into something like the unix "file" command 17:19:30 <planetmaker> ah, you mean bananas grfID tool? 17:19:31 <frosch123> planetmaker: bananas uses the "grfid" tool to check whether the uploaded file is a newgrf 17:19:35 <planetmaker> :-) 17:19:53 <frosch123> afaik it is included in the grfcodec package as well today 17:22:00 <planetmaker> yes 17:32:36 <planetmaker> http://wiki.openttd.org/Frosch/GRF_Version_8 17:38:47 <Ammler> [18:55] <Rubidium> and the reason against going for defaulting to windows is because it's simply the lesser quality palette <-- it's not really default it's more like a convention how do handle unaction14ed newgrfs 17:41:15 <Ammler> I would not communicate it like default palette is windows :-) 18:03:35 <Rubidium> Ammler: which basically removes any incentive to set it 18:22:11 *** andythenorth has joined #openttdcoop.devzone 19:19:18 <Yexo> but there is currently not an incentive to set it either 19:19:29 <Yexo> the only way to provide that would be to change opengfx to the dos palette 19:19:47 <Yexo> however since that "breaks" many newgrfs, that's not a good diea 19:21:05 <frosch123> hmm, how did it happen that the "default cargo" issue was missing in the list :s 21:00:03 *** ODM has quit IRC 21:11:12 <Brot6> NewGRF Meta Language - Feature Request #2577: autoconvert palette if possible (planetmaker) @ http://dev.openttdcoop.org/issues/2577#change-6655 21:15:41 <Yexo> planetmaker: thanks. Is the extra code in main.py your only modification? 21:15:51 <planetmaker> yes 21:18:46 <planetmaker> and if you build the test case as described the newgrf will work. But the shore tiles will suddently have grid lines again ;-) 21:18:54 <planetmaker> Thus you'll notice the (expected) difference 21:29:58 *** andythenorth has left #openttdcoop.devzone 21:40:58 <frosch123> planetmaker: slightly updated the wiki btw 21:57:34 *** frosch123 has quit IRC