Config
Log for #openttdcoop.devzone on 30th April 2011:
Times are UTC Toggle Colours
00:06:46  *** KenjiE20 has quit IRC
01:09:08  *** Hirundo has quit IRC
01:09:09  *** V453000 has quit IRC
01:09:39  *** Webster has joined #openttdcoop.devzone
01:10:18  *** Brot6 has joined #openttdcoop.devzone
01:10:53  *** tneo has joined #openttdcoop.devzone
01:11:23  *** Hirundo has joined #openttdcoop.devzone
01:11:23  *** SmatZ has joined #openttdcoop.devzone
01:12:00  *** Ammler has joined #openttdcoop.devzone
01:13:23  *** V453000 has joined #openttdcoop.devzone
01:13:23  *** Terkhen has joined #openttdcoop.devzone
01:13:23  *** XeryusTC has joined #openttdcoop.devzone
01:13:53  *** Yexo has joined #openttdcoop.devzone
01:13:53  *** avdg has joined #openttdcoop.devzone
01:14:23  *** DJNekkid has joined #openttdcoop.devzone
01:14:53  *** planetmaker has joined #openttdcoop.devzone
01:28:06  *** Anson has joined #openttdcoop.devzone
02:44:00  *** Anson has left #openttdcoop.devzone
03:43:57  *** Lakie has quit IRC
05:51:27  *** ODM has joined #openttdcoop.devzone
08:32:22  *** LordAro has quit IRC
10:50:22  *** KenjiE20 has joined #openttdcoop.devzone
11:29:13  <Brot6> OpenGFX+ Trains - Revision 238:cb199b3d4f24: Doc: Update readme a bit wrt build requirements and ... (planetmaker) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/cb199b3d4f24
11:29:14  <Brot6> OpenGFX+ Trains - Revision 239:eff3c225c47b: Fix: Asiastar and TIM were truncated in height in th... (planetmaker) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/eff3c225c47b
11:35:12  <Ammler> - python 2.5+ with yacc, pil modules installed <-- not a requirement of a grf to build
11:35:58  <Ammler> or is ogfx+trains special? :-)
11:36:40  <Yexo> Ammler: why is that not a requirement? it's needed for nml
11:36:50  <Ammler> exactly, not for the grf
11:37:10  <Ammler> it should be part of the nml installation instructions
11:38:14  <Yexo> true, as long as nml is properly listed as requirement for the grf
11:38:29  <Ammler> which he did
11:39:16  <Ammler> well, maybe he doesn't trust the nml readme ;-)
11:45:58  <Ammler> Yexo: a little feature request on the nml nfo: "T" "NAME" 0C "OpenGFX+ 列車 nightly-r237" 00  <-- couldn't it use the code instead "Þ"
11:46:32  <Yexo> I don't understand your request
11:46:46  <Ammler> hmm, my irc client filtered it
11:47:11  <Ammler> there was Þ in front of "OpenGFX..."
11:47:26  <Yexo> as there should be
11:47:50  <Ammler> no, there should be the hex code (2 byes)
11:47:57  <Ammler> hmm, I need to check it
11:49:40  <Yexo> http://wiki.ttdpatch.net/tiki-index.php?page=StringCodes also mentions: "start it with a capital thorn (U+00DE, "Þ"),"
11:53:08  <Ammler> yeah, but can write that with a byte code
11:53:34  <Ammler> since I converted to nml, I have no newgrf where I used that
11:54:29  <Yexo> where you used what?
11:55:11  <Yexo> I see no reason for writing C3 9E to the nfo instead of the capital thorn
11:55:44  <Yexo> since it's always at the start of the string that makes it easy to read to C3 9E bytes as part of the action bytes instead of the string
11:56:23  <Ammler> it looks ugly
11:56:31  <Ammler> and my client didn't write it
11:56:44  <Yexo> that's a problem of your client
11:57:01  <Ammler> yeah, but then I have still the first issue :-)
11:57:43  <Yexo> go try and make utf-8 default for nfo v8, than there is no need anymore
11:58:13  <Ammler> it is just much "safer" to write it that way
11:58:33  <Ammler> just ask rubi, he had to fix a lot such issues on opengfx
11:59:44  <Rubidium> those were non-UTF8 strings in comments
12:00:04  <Rubidium> that broke horribly if someone with a sanely configured editor opened the file
12:00:24  <Yexo> as in, byte values 128-255 in an otherwise utf-8 file?
12:00:46  <Rubidium> Yexo: well, more a file with undefined charset
12:00:55  <Yexo> yes, ok
12:01:11  <Rubidium> IIRC it was also with the decoded colour translations
12:01:13  <Yexo> which has nothing to do with wriing C3 9E or "Þ"
12:01:18  <Rubidium> that got converted into unicode
12:01:34  <Rubidium> uhmm... why do I say unicode when I don't mean that
12:01:48  <Rubidium> it converted it into iso8859-1 or something
12:01:58  <Yexo> ah, right
12:02:07  <Rubidium> which got broken by the first person opening it in an utf8 editor (i.e. me!)
12:02:45  <Rubidium> so I wrong those colour translations fully in %02x instead of partly iso8859-1
12:02:48  <Yexo> that sounds like a bug in grfcodec
12:02:51  <Rubidium> s/wrong/rewrote/
12:03:31  <Rubidium> Yexo: not quite a bug, more an omission of knowledge
12:03:38  <Yexo> recolour sprites are only valid where real sprites are valid, ie after action1/5/9
12:03:54  <Yexo> although I'm not sure if grfcodec even has knowledge of that
12:04:11  <Rubidium> as (hopefully globally) known grfcodec has no knowledge of what data is what (besides sounds and sprites)
12:04:42  <Rubidium> so everything that isn't sound or a real sprite will go through the "is this text, and if so write it out as text" filter
12:04:57  <Yexo> I thought for a moment it did know a little bit to make a difference between real sprites and action data, but indeed it doesn't even need that little bit
12:05:04  <Rubidium> and text is anything that's considered printable with iso8859-1
12:05:50  <Rubidium> as such, large parts of recolour sprites are seen as text if you enable (or not disable) the "try to find text and make it look like text" feature
12:06:11  <Yexo> it could be changed to only consider 0-127 printable
12:06:46  <Rubidium> but then it fails for many valid strings
12:06:59  <Yexo> nforenum -b+ could fix that
12:07:14  <Yexo> failing to convert bytes to string representation doesn't result in any errors
12:07:22  <Yexo> converting too much does
12:07:35  <Rubidium> but... it's still valid nfo
12:07:48  <Rubidium> it's only what editors do to it at a later stage
12:08:07  <Rubidium> which is somewhat the reason why we use only ASCII in OpenTTD's source files
12:08:19  <Rubidium> as compilers might not always convert utf8 properly
12:09:24  <Yexo> it might still be valid nfo but having a single file with both ido8859-1 encoded strings and utf-8 strings is never a good idea
12:11:13  <Rubidium> but grfcodec is unaware of that
12:11:37  <Yexo> yes, but it can also easily avoid it
12:11:46  <Rubidium> but feel free to improve it ;)
13:54:03  *** frosch123 has joined #openttdcoop.devzone
14:58:41  *** Lakie has joined #openttdcoop.devzone
17:01:59  *** MinchinWeb has joined #openttdcoop.devzone
17:12:33  <MinchinWeb> any ideas what would cause an AI to fail to compile?  http://www.tt-forums.net/download/file.php?id=144035
17:14:48  <frosch123> even info.nut fails :o
17:15:38  <MinchinWeb> that's slightly comforting becuase that means it's not my AI!
17:17:05  <MinchinWeb> but the files from the NoAI team's librarys don't fail (and they should be there, although I can't confirm that, but they should have been downloaded with WmDOT)
17:18:35  <Brot6> ogfx-trains: update from r237 to r239 done - http://bundles.openttdcoop.org/ogfx-trains/nightlies/r239
17:19:41  <Brot6> opengfx: update from r651 to r656 done - http://bundles.openttdcoop.org/opengfx/nightlies/r656
17:19:48  <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 (r617), frenchtowns (r6), german-townnames (r33), grfcodec (r828), grfpack (r279), heqs
17:19:48  <Brot6> (r605), indonesiantowns (r41), manindu (r7), metrotrackset (r56), narvs (r37), newgrf_makefile (r285), nml (r1323), nutracks (r186), ogfx-industries (r53), ogfx-landscape (r60), ogfx-rv (r80), ogfx-trees (r42), openmsx (r97), opensfx (r97), smts (r19), snowlinemod (r49), spanishtowns (r10), swedishrails (r202), swisstowns (r22), transrapidtrackset (r15), ttdviewer (r26), ttrs (r36), worldairlinersset (r671)
17:20:13  <Yexo> MinchinWeb: if you start openttd with -d ai=9, do you get more output either there or in the console window?
17:22:38  <MinchinWeb> Yexo: it's not on my machine...I get nothing
17:22:51  <MinchinWeb> it's a guy trying to load my AI
17:23:10  <Yexo> does you info.nut include any library?
17:23:31  <Yexo> not having a required library might cause a compile failure, not sure about that
17:24:05  <MinchinWeb> yeah, it requires libraries there
17:24:13  <Yexo> that might be the reason
17:25:04  <planetmaker> have you set those libs as dependency on bananas, MinchinWeb ?
17:25:14  <planetmaker> or is that guy trying to install manually?
17:25:19  <MinchinWeb> yeah, I'll double check
17:25:38  <MinchinWeb> do you need to list dependencies of dependicies?
17:25:49  <planetmaker> I don't think so
17:26:08  <planetmaker> but... I'm not sure :-)
17:26:57  <MinchinWeb> I have both direct dependencies listed (SuperLib and my MetaLib)
17:26:58  <Yexo> ^^ same here
17:28:14  <Yexo> MinchinWeb: another odd thing in that screenshot is that "SuperPF/library.nut" is not in a tar file
17:32:44  <MinchinWeb> indeed...
17:50:47  *** KenjiE20 has quit IRC
17:51:48  *** KenjiE20 has joined #openttdcoop.devzone
18:44:15  *** DanMacK has joined #openttdcoop.devzone
19:26:56  *** MinchinWeb has quit IRC
19:28:09  *** MinchinWeb has joined #openttdcoop.devzone
20:16:51  *** MinchinWeb has quit IRC
20:18:01  <planetmaker> btw, frosch123 did I already mention that the ttdsprite viewer of yours can be a great help? :-)
20:19:51  <frosch123> no :)
20:20:29  <planetmaker> well, so "thank you" for it :-)
20:21:07  <planetmaker> what I wondered: are the "unused" palettes there correct as they are all the same (it appears)?
20:21:21  <planetmaker> they have interesting effects ;-)
20:21:49  <planetmaker> and seem to be meant for more water-rich things
20:21:54  <planetmaker> or maybe space
20:22:26  <frosch123> iirc, they are different
20:22:34  <planetmaker> and I wished it would allow to save sprites with the palette converted dos <-> windows ;-)
20:23:29  <frosch123> what did you use it for btw? :)
20:23:42  <frosch123> seems like the 3 unused ones only differ in some colours
20:24:39  <planetmaker> many action colours change. And some others, too. And the pink ones.
20:25:00  <planetmaker> I used it to check re-colour properties of sprites
20:25:09  <planetmaker> whether they do what they're meant to do
20:25:12  <frosch123> ah, the bridge stuff :)
20:25:19  <planetmaker> yes, and then continued from there
20:25:50  <planetmaker> it's really great use for this. No other tool can check that as quickly; ingame is not faster ;-)
20:27:15  <planetmaker> and I will continue to use it to check sprites for (spurious) action colours
20:27:25  <planetmaker> quite powerful for these things
20:28:49  <frosch123> one could add custom recolourings for that
20:29:26  <frosch123> or only draw the action coloured pixels or similiar
20:30:04  <planetmaker> well, they quickly become visible
20:30:48  <planetmaker> conversion between palettes would be more urgently needed :-P
20:31:34  <planetmaker> though... thinking of it, it could be a feature request for nml ;-)
20:31:39  <planetmaker> automatically do the right thing (TM)
20:32:02  <planetmaker> as a translation dos <-> win should be (nearly) uniq
20:32:13  <planetmaker> at least win->dos
20:32:17  <Yexo> win->dos yes, dos->win not
20:32:21  <planetmaker> :-)
20:32:22  <Yexo> as there are some colors that can't be converted
20:33:05  <planetmaker> I thought about having dos the default palette for nml. and silently converting windows to dos. Unless command line parameter tells to use windows
20:33:10  <planetmaker> yes
20:33:48  <planetmaker> I'm not sure how much trouble that would be to add, though
20:33:49  <Yexo> what if nml determines that all input files are windows paletted? still write dos palette to grf?
20:34:12  <planetmaker> :-) does it know that in advance?
20:34:31  <planetmaker> technically it probably is easier to go with "use dos unless asked to use windows"
20:34:32  <Yexo> yes
20:34:41  <planetmaker> and in the latter case just require all input to actually be windows
20:34:53  <Yexo> it scans the palette of all graphics files used before starting to write the grf/nfo file
20:35:00  <planetmaker> ah, ok
20:35:54  <Yexo> so I was thinking: "command line win: input must be win. command line dos: input either dos or win. command line nothing, input is all win: output win, otherwise output dos"
20:35:58  <planetmaker> Let's say: it'd help me writing the (new) NewGRFs in the DOS palette. There's still many snippets and old sprites which are windows and it save me quite a bit manual conversion work
20:36:13  <planetmaker> that sounds good as well
20:36:57  <Yexo> and maybe allow dos->win too when no dos-only colors are used
20:37:03  <Yexo> but that depends how hard it is to code that :p
20:37:10  <frosch123> be careful with text colours
20:37:24  <Yexo> text colours?
20:37:31  <frosch123> they are always 0-2, independent of palette
20:37:54  <frosch123> the colours uses for characters :)
20:37:58  <frosch123> in action a and 12 (?)
20:38:00  <Yexo> so no converting of sprites in a font_flyph block
20:38:19  <frosch123> yup
20:38:20  <Yexo> hmm, font in action A? I don't see how to detect that
20:38:29  <frosch123> spritenumbers?
20:38:58  <Yexo> action A in nml accepts all expressions, not just constant numbers
20:39:00  <frosch123> 2 - 386 or so?
20:39:16  <Yexo> in fact that's necessary to support sprite GRM
20:39:30  <frosch123> hmm, true, but that makes no sense for characters
20:39:39  <Yexo> ah, right
20:39:55  <planetmaker> don't worry, if it's a non-constant expression, but notify if it's constant and a character?
20:39:59  <frosch123> well, characters make only sense in base graphics anyways, so action a is not that important
20:40:18  <planetmaker> frosch123: some newgrf authors might disagree :-P
20:40:38  <frosch123> :p
20:41:15  <Yexo> another option would be to detect usage of colors 0-2 without any other colors in a sprite
20:42:05  <planetmaker> that might be dangerous
20:42:20  <planetmaker> though I know of no example
20:42:37  <Yexo> it could be a good extra check though
20:42:56  <Yexo> make sure sprites 2-386 (or whatever the valid range is) are actually character sprites
20:42:56  *** Lakie has quit IRC
20:43:43  *** Lakie has joined #openttdcoop.devzone
20:48:35  <frosch123> hmm, actually text colours are no problem with you convert to dos
20:48:56  <frosch123> 0-2 do not need conversion in that case
20:49:14  <frosch123> s/with/if/
21:55:07  *** ODM has quit IRC
22:00:02  *** frosch has joined #openttdcoop.devzone
22:04:41  *** frosch123 has quit IRC
22:34:44  <planetmaker> http://imagebin.org/151066 vs http://imagebin.org/151067 - which is nicer?
22:34:45  <Webster> Title: Imagebin - A place to slap up your images. (at imagebin.org)
23:34:19  *** Lakie has quit IRC

Powered by YARRSTE version: svn-trunk