Log for #openttdcoop.devzone on 3rd May 2011:
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
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>
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
15:38:10  <Brot6> NewGRF Meta Language - Feature Request #2577 (New): autoconvert palette if possible (planetmaker) @
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) @
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) @
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) @
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:
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> <-- 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>
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) @
21:15:41  <Yexo> planetmaker: thanks. Is the extra code in 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

Powered by YARRSTE version: svn-trunk