IRC logs for #openttd on OFTC at 2012-02-08
⏴ go to previous day
00:08:07 *** Cybertinus has joined #openttd
00:40:43 *** Stimrol_ has joined #openttd
00:49:37 *** Aygar[Work|afk] has quit IRC
00:49:38 *** devilsadvocate has quit IRC
00:50:45 *** Cybertinus has joined #openttd
00:50:45 *** Xrufuian has joined #openttd
00:50:45 *** kkb110__ has joined #openttd
00:50:45 *** Rhamphoryncus has joined #openttd
00:50:45 *** Belugas has joined #openttd
00:50:45 *** tokai|mdlx has joined #openttd
00:50:45 *** confound has joined #openttd
00:50:45 *** tparker has joined #openttd
00:50:45 *** Aygar[Work|afk] has joined #openttd
00:50:45 *** devilsadvocate has joined #openttd
00:50:45 *** glevans2 has joined #openttd
00:50:45 *** Arafangion has joined #openttd
00:50:45 *** Maarten has joined #openttd
00:50:45 *** Rubidium has joined #openttd
00:50:45 *** mikegrb has joined #openttd
00:50:45 *** charon.oftc.net sets mode: +oovo Belugas Rubidium Rubidium orudge
00:50:45 *** TinoDidriksen has joined #openttd
00:50:45 *** Born_Acorn has joined #openttd
00:50:45 *** ccfreak2k has joined #openttd
00:50:45 *** welshdragon has joined #openttd
00:50:45 *** EyeMWing has joined #openttd
00:50:45 *** jonty-comp has joined #openttd
00:50:45 *** charon.oftc.net sets mode: +v orudge
00:51:25 *** ChanServ sets mode: +v DorpsGek
01:25:28 *** Keyboard_Warrior has quit IRC
01:56:09 *** Keyboard_Warrior has joined #openttd
02:44:48 *** Markavian has joined #openttd
03:18:25 *** Keyboard_Warrior has quit IRC
03:24:25 *** Keyboard_Warrior has joined #openttd
03:26:09 *** kkb110__ has joined #openttd
04:01:35 *** Keyboard_Warrior has quit IRC
04:31:40 *** cmircea has joined #openttd
05:02:42 *** Stimrol has joined #openttd
05:14:02 *** tokai|noir has joined #openttd
05:14:03 *** ChanServ sets mode: +v tokai|noir
05:23:48 *** michi_cc has joined #openttd
05:23:48 *** ChanServ sets mode: +v michi_cc
05:59:35 *** theholyduck has joined #openttd
05:59:50 *** kkb110__ has joined #openttd
06:23:48 *** devilsadvocate has quit IRC
06:24:07 *** roboboy has joined #openttd
06:33:47 *** sla_ro|master has joined #openttd
06:38:19 *** JVassie has joined #openttd
06:58:59 *** theholyduck has joined #openttd
07:06:56 *** devilsadvocate has joined #openttd
07:20:34 *** devilsadvocate has quit IRC
07:37:29 *** devilsadvocate has joined #openttd
07:40:35 *** Progman has joined #openttd
07:46:21 *** Twofish has joined #openttd
07:54:20 *** TWerkhoven[l] has joined #openttd
07:58:13 *** devilsadvocate has quit IRC
07:59:27 *** devilsadvocate has joined #openttd
08:15:40 *** andythenorth has joined #openttd
08:22:51 *** andythenorth is now known as Guest1898
08:22:51 *** andythenorth has joined #openttd
08:35:30 *** DayDreamer has joined #openttd
08:35:41 *** DayDreamer has left #openttd
08:41:39 *** andythenorth has joined #openttd
08:47:30 *** lmergen has joined #openttd
09:26:27 * andythenorth has half a day off
09:26:30 <andythenorth> what will I code?
09:28:21 <murr4y> you will... create pacman in coffescript
09:29:03 <andythenorth> pacman in newgrf + AI might be interesting
09:29:11 <andythenorth> newgrf + AI + nogo
09:31:17 * andythenorth will probably do BANDIT instead
09:31:46 <andythenorth> maybe truck purchase cost and run cost can be calculated
09:35:42 <andythenorth> how many levels of indirection are too many? :P
09:36:42 <andythenorth> truck cost coefficient -> truck cost derived from weight, length, speed, hp etc -> running cost factor in nfo -> base cost -> game difficulty settings -> result
09:43:20 <andythenorth> dealing with things that vary by consist length just got a lot easier
09:43:31 <andythenorth> e.g. truck where more trailers = more weight, higher run cost
09:43:40 <andythenorth> I can just chain method calls from the template
09:44:00 <andythenorth> e.g. return ${vehicle.get_run_cost(trailers=1)}
09:44:27 <andythenorth> that method would chain to self.get_weight(trailers=trailers)
09:44:32 <andythenorth> returning a result
10:06:46 *** tokai|mdlx has joined #openttd
10:11:21 *** ChanServ sets mode: +v tokai
10:39:22 <peter1138> what, no complete 32bpp ez set yet?
10:53:04 *** tokai|mdlx has joined #openttd
11:17:37 *** lmergen has joined #openttd
11:30:06 <Rubidium> peter1138: yeah, all the effort we put in to get 32bpp ez support in trunk and they still are not using it...
11:30:28 <Rubidium> next they'll say that you need an ancient version of OpenTTD to get 32bpp ez support
11:36:44 <Ammler> planetmaker: should include 32bpp to opengfx :-P
11:37:04 <Rubidium> then $someone must at 32bpp support to nml
11:37:59 <Rubidium> there's already a patch for grf container version 2 floating around somewhere
11:38:05 <Ammler> hmm, I thought that is in long ago or just ez?
11:38:32 <Rubidium> the old method got axed
11:38:50 <Rubidium> as it's horridly slow
11:39:51 <peter1138> nml's not patched? heh
11:40:21 <Rubidium> not for storing 32bpp sprites in the GRF
11:43:48 <Ammler> are there already 32bpp grfs on bananas?
11:45:10 <peter1138> does/will bananas handle handing out stripped grfs?
11:45:57 <Rubidium> no/when somebody codes that
12:23:50 <planetmaker> changing bananas to strip the EZ sprites IMHO has less priority than making such (New)GRFs in the first place
12:23:58 <planetmaker> and Ammler : yes, it should include those
12:24:03 <planetmaker> When NML supports it
12:24:09 <planetmaker> it should also support EZ 8bpp
12:33:01 *** tokai|noir has joined #openttd
12:33:01 *** ChanServ sets mode: +v tokai|noir
12:33:59 <planetmaker> Ammler, I'd very welcome to get collections of usable blender files which could be used for this end
12:34:07 <planetmaker> some buildings certainly might apply
12:38:37 <Ammler> planetmaker: currently I would like to get opengfx/nml working for 8bpp :-)
12:39:54 <Ammler> someone any clue what those sprites are?
12:40:41 <Ammler> yes, are you able to point me to the source?
12:40:46 <planetmaker> looks like ogfx+extra
12:40:59 <planetmaker> sprites/nml/extra/rivers.pnml or so
12:41:12 <Ammler> new is by nml/pytnon 2.7, the others are randomly different
12:41:22 <Ammler> planetmaker: or so :-P
12:41:53 <Ammler> but any clue, why there are such sprites?
12:42:03 <planetmaker> the garbled ones?
12:42:13 <planetmaker> no idea whatsoever
12:42:14 <Ammler> those aren't in the official release
12:42:24 <planetmaker> they're generated by gimp
12:42:27 <planetmaker> maybe that fails?
12:42:36 <planetmaker> yes, iirc they are
12:42:44 <Ammler> gimp and without gimp produces the same result
12:43:37 <planetmaker> you should be able to treat rivers.pnml basically as a separate grf, if you add a header
12:43:39 *** roboboy has joined #openttd
12:43:46 <planetmaker> thus you'd have a small test case. Relatively small.
12:43:51 <planetmaker> It might still be 1k sprites
12:44:19 <Ammler> yes, that does also not help me find those sprites
12:44:53 <Ammler> what we know is that those images aren't part of the source, right?
12:45:16 <Ammler> so they are generated by nml, but why?
12:45:31 *** tokai|mdlx has joined #openttd
12:46:56 <planetmaker> NML cannot generate images
12:47:08 <planetmaker> but of course it writes the grf, thus extracts it from the pngs
12:47:22 <planetmaker> it's worth looking which (source pngs) end up garbled
12:47:43 <Ammler> yes, but how would you find those?
12:48:08 <planetmaker> compile the pnml to nfo and lookup the sprite number
12:48:26 <planetmaker> nmlc --nfo blub.nfo rivers.pnml
12:48:26 <Ammler> I have the sprite number
12:48:32 <planetmaker> yes. But then you know which
12:48:57 <planetmaker> but it looks to me like temperate river mouths
12:49:08 <planetmaker> not sure whether there are empty sprites
12:49:14 <planetmaker> like only transparent. Worth looking into
12:49:21 <Ammler> well, the release skips those sprites
12:49:39 <Ammler> as you see on new, those are 0,0
12:51:17 <planetmaker> you're comparing default branch and 0.4 branch?
12:51:34 <planetmaker> I don't think (nor hope) so
12:51:53 <planetmaker> so where does 'release' come into it?
12:52:03 <Ammler> I compare grf made with python 2.7
12:52:10 <Ammler> to grf made with python 2.6
12:52:30 <planetmaker> good. py2.6 = old and py2.7 = new, right?
12:52:48 <planetmaker> both from the opengfx 0.4 branch, same revision
12:54:12 <Ammler> (might need some time to load)
12:54:17 <planetmaker> let's test (here) with py 2.5
12:54:28 <Ammler> then compare the md5sum
12:55:04 <Ammler> you will have those strange random sprites
12:56:01 <Ammler> it is like you use broken images there and newer python ignores it
12:56:05 <planetmaker> this machine is quite slow. So expect results in 30 minutes+ :-)
12:56:17 <Ammler> you can safely disable gimp
12:57:20 <Ammler> planetmaker: I just wonder, shouldn't it be easy to find set2 easy in the nml code?
12:57:57 <planetmaker> yes... did you look at the nml?
12:58:08 <planetmaker> then you'd quickly find the rivermouths block
12:58:25 <planetmaker> for temperate climate
13:00:38 <V453000> compiling opengfx takes 30 minutes?
13:00:50 *** lmergen has joined #openttd
13:01:18 <planetmaker> if you create each and every image from the gimp source files it may. Depending on speed of your computer
13:01:29 <Ammler> set_rivermouth_snow <-- set2 right?
13:01:54 <Ammler> and gimp does not allow running parallel threads
13:02:14 <Ammler> so it indeed takes much longer to build opengfx than openttd :-)
13:02:24 <planetmaker> Ammler, from the gfx it looks like it really should be rivermouths_temperate - and not the snowy one
13:02:29 <planetmaker> might be re-ordered by nml
13:03:02 <Ammler> planetmaker: so the first one in thes ource?
13:03:43 <planetmaker> compare with the png :-)
13:04:40 <Ammler> [ 241, 1, 64, 23, -31, 0, "sprites/png/terrain/waterfeatures/rivermouth_temperate_ne.gimp.png"] <-- so the first bad one
13:05:56 *** HerzogDeXtEr has joined #openttd
13:08:02 <Ammler> first view, it doesn't look bad
13:08:36 <Ammler> all gimp pngs in that folder are at least 8bit indexed
13:08:38 <planetmaker> looks like a normal png
13:08:48 <planetmaker> those probably aren't even generated by gimp. Not sure though
13:09:19 <Ammler> well, they end with gimp.png, shouldn't they then?
13:11:46 <Ammler> nmlc: "input", line 13: Encountered unknown template identifier: tmpl_level_ground_file <-- not that easy to build just the rivers nml
13:11:47 <planetmaker> it should rather use rivermouth_temperate_XX.gimp.png
13:12:05 <planetmaker> just copy - paste that template file then
13:12:19 <Ammler> well, I have no clue, how that would help
13:12:30 <planetmaker> makes for a smaller grf to build
13:12:46 <planetmaker> and one could then cut-out those sets which are the same
13:13:01 <planetmaker> thus target the point it fails more closely
13:13:11 <planetmaker> like you could slash away the climate switch
13:13:23 <planetmaker> and only make temperate rivers then
13:14:26 <planetmaker> ha, gimp is done creating pngs for ogfx1_base.grf :-)
13:14:55 <Ammler> you don't need gimp for this check
13:15:11 <planetmaker> yes, still I want to build OpenGFX on python 2.5 to check
13:15:19 <planetmaker> and thus I need to run make completely
13:16:36 <planetmaker> Ammler, which NML version did you use to obtain the respective results?
13:18:37 <planetmaker> ok. Hm. I build this one now with 0.2.x head
13:20:50 <Ammler> there you can click on the build status "succeeded or failed" and get the full build log
13:21:13 <Ammler> there is also a package openttd-opengfx-without-gimp
13:22:53 <planetmaker> btw, Ammler, that I see that page: Could you change the description for OpenGFX
13:23:11 <planetmaker> It's a "graphics baseset for OpenTTD"
13:23:16 <planetmaker> And not a replacement :-)
13:26:03 <planetmaker> also it does not supply all required base set files. It has no sound. But NoSound is integral part of OpenTTD, so a missing sample.cat won't be noticed
13:26:26 <planetmaker> anyway, are you around tonight, Ammler ?
13:26:37 <Ammler> oh well, I do but this discription is not really public..., there is uses the desc from the spec
13:26:45 <Ammler> planetmaker: yes, I am
13:26:50 <planetmaker> I'd like to postpone further investigation till then
13:26:59 <planetmaker> work work and RL ;-)
13:27:18 <planetmaker> well, still. Official or not. The desc there sounds quite wrong to me :-)
13:27:40 <Ammler> OpenGFX is an open source graphics base set designed to be used by OpenTTD.
13:27:41 <Ammler> OpenGFX provides a set of free and open source base graphics, and aims to
13:27:43 <Ammler> ensure the best possible out-of-the-box experience with OpenTTD.
13:28:30 <planetmaker> maybe we should replace the "desgined to be used by" with a "for"
13:30:26 <Ammler> no clue, where I have that from, readme?
13:30:57 <Ammler> It's for sure not my own invention :-)
13:36:14 *** Markavian has joined #openttd
13:43:08 <planetmaker> no, it's my invention
13:43:23 <planetmaker> or rather we discussed it some time (year?) ago
13:43:48 <Ammler> the summaries and descriptions might need some review anyway
13:43:51 <planetmaker> for sure there's a bug tracker issue about it
13:44:04 <planetmaker> most likely closed since then, though
13:44:11 <Ammler> since opengfx are the default graphics for openttd ;-)
13:50:56 <Ammler> or if you find something else, just tell
13:51:23 *** andythenorth has joined #openttd
13:54:11 <planetmaker> 0c351293517a91ed76ebef1239e3c10d ogfxe_extra.grf with python 2.5.2
13:54:46 <Ammler> but pure white is something new
13:58:06 *** swissfan91 has joined #openttd
13:58:38 <planetmaker> anyway, the resulting grf has also the garbled real sprites
14:00:59 <swissfan91> anyone got any ideas of any landscape objects that would fit in an alpine landscape?
14:01:46 <andythenorth> animated avalance
14:02:06 <Ammler> cablecar is a railtype :-)
14:03:22 <swissfan91> trees - I'm not skilled enough for. Hiking hut - Yes!. Snow groomer - already part of TARS pistes. goats - Yes!. cable car - already part of TARS Mountain Lifts. Summit cross - Yes!. Avalanche - o_o.
14:03:51 <swissfan91> outlook tower - possibly. sheep fold - part of TARS industry. picnic place - yes.
14:05:11 <swissfan91> i presume it is possible to change river sprites to appear completely iced over when above the snowline?
14:05:24 <planetmaker> oh, and a restaurant as new object to be placed on hills etc
14:05:42 <swissfan91> restaurant - TARS pistes/TARS town objects
14:05:59 <Ammler> planetmaker: also If I found the bad sprites, what should I do then?
14:06:00 <planetmaker> well. it's feasible. But I'd not do that as it will give weired results
14:06:09 <planetmaker> Ammler, not sure :-)
14:06:13 <planetmaker> find out why it's bad
14:06:26 <planetmaker> swissfan91, boats can still go there, so it should remain shippable
14:06:41 <planetmaker> thus: mostly ice free rivers
14:06:56 <planetmaker> I DO have river sprites with icy edges and also snow transition in OpenGFX
14:07:22 <Ammler> apline has no frozen rivers
14:07:23 <planetmaker> one could add a few ice pieces floating around there for the full snow version
14:07:30 <Ammler> at least not that I am aware of
14:07:31 <planetmaker> but... rivers in the alps aren't frozen
14:07:32 <swissfan91> I was thinking if they were fully iced, then glaciers could be drawn easier
14:07:35 <planetmaker> they're too steep and too rapid
14:07:45 <planetmaker> wrong approach, swissfan91
14:07:48 <planetmaker> glaciers = objects
14:08:23 <swissfan91> I agree with the floating ice pieces idea. that would look nice.
14:08:43 <swissfan91> perhaps having a large area with glacier newobjects placed on, and then that funnelling into an icy river
14:08:43 <Ammler> and make the glacier shrink during time :-)
14:09:18 <Ammler> glacier have half size compared to 50 years back?
14:09:39 <swissfan91> that would take some very clever coding, no?
14:10:55 <swissfan91> I think my first thing to change - when I have time - will be to add snow/rock transitions.
14:11:46 <Ammler> you could ask SAC for help :-P
14:12:36 <swissfan91> i'm hoping to release a teaser version of TARS objects very soon.
14:12:43 <swissfan91> which I hope will ignite some interest.
14:14:13 <andythenorth> variable running costs - according to load amount?
14:17:18 <planetmaker> no game play effect
14:17:34 <planetmaker> i.e.: work not well spend IMHO
14:18:27 <swissfan91> does OTTD have a wind direction?
14:18:48 <andythenorth> variable running costs - less while not moving?
14:18:53 <planetmaker> look at the small airport or the coal powerplant, swissfan91
14:19:13 <andythenorth> ottd has two wind directions afaik
14:23:14 <Ammler> how boring would it be with one only
14:23:20 <Elukka> wind direction is like the least important thing
14:23:29 <Elukka> wind goes more than one way in real life :P
14:24:21 <Ammler> but maybe a good idea to have same wind direction per object
14:26:02 <Ammler> hmm, where goes smoke of a standing stream?
14:26:46 <Ammler> rather diesel maybe :-)
14:27:17 <swissfan91> true, but then you could argue that light direction changes in real life.
14:27:32 <swissfan91> i only asked in case there was one standard direction that people used when drawing.
14:27:38 <Ammler> well, there you have the issue that train is in motion,
14:27:47 <planetmaker> most orient wind on the power plant
14:27:51 *** tokai|noir has joined #openttd
14:27:51 *** ChanServ sets mode: +v tokai|noir
14:28:56 <Ammler> swissfan91: I hope you ask so you can draw it to another direction :-P
14:29:34 <swissfan91> i'm only making a quick flagpole so TARS landscapes has something in it for the teaser :P
14:34:24 <swissfan91> that's a quick attempt at it
14:36:31 *** tokai|mdlx has joined #openttd
14:37:07 *** lmergen has joined #openttd
14:37:18 <planetmaker> bah, I know (again) why I hate imageshacks
14:37:34 <planetmaker> slow. works poorly. overloaded with ads.
14:37:42 <planetmaker> and I still don't see the image
14:38:09 <planetmaker> even after I disabled adblock+ for that page
14:38:55 <planetmaker> I call that usual
14:39:07 <Ammler> blocker scripts suck anyway
14:39:13 <swissfan91> odd in that I see it fine when I click it.
14:41:20 <TinoDidriksen> Works fine for me with NoScript and AdBlock+
14:44:27 <Ammler> planetmaker: I think, as gimp isn't the issue, it should rather be a png which isn't from gimp
14:47:46 <Ammler> hmm, and waterfeatures.png is decoded png :-(
14:49:44 <Ammler> spriteset(set_rivermouth_temperate, "") <-- couldn't you "hardcode" the set number?
14:50:52 *** TWerkhoven[l] has joined #openttd
14:52:19 <andythenorth> Ammler: planetmaker what problem are you solving?
14:52:48 <planetmaker> different grf on different python. Most problematic are some garbled real sprites
14:53:05 <Ammler> and of course, since nml doc is on same wiki with nfo, search is useless :-)
14:53:19 <andythenorth> have you narrowed down which pythons?
14:53:41 <andythenorth> I have 2.6.1, want me to test?
14:53:53 <planetmaker> yes. Build ogfxe_extra from OpenGFX
14:53:56 <andythenorth> it's likely PIL, or a dep (like the png library if that's separate)
14:54:00 <andythenorth> but I guess you know that :P
14:54:03 <planetmaker> run grf2html and look at the real sprites ^^
14:54:31 <andythenorth> I'll checkout and such
14:54:47 <andythenorth> is this in the OpenGFX repo?
14:54:53 <planetmaker> mind, build the 0.4 branch of OpenGFX. Which wants NML 0.2.x
14:55:20 <planetmaker> thus I first need to "up" my NML to the 0.2 branch ;-)
14:55:20 <Ammler> planetmaker: is it different with ogfx default?
14:55:23 <andythenorth> I'll have to up NML
14:55:30 <planetmaker> Ammler, I didn't test
14:56:38 <planetmaker> Ammler, but the sprite numbers would be different at least since I could cut quite a bit which is backward compatibility to OpenTTD <= 1.1
14:56:40 <andythenorth> is there a target for building ogfxe_extra?
14:57:01 <planetmaker> there's not. Unless you could try "make ogfxe_extra.grf"
14:57:02 *** tokai|noir has joined #openttd
14:57:02 *** ChanServ sets mode: +v tokai|noir
14:57:10 <planetmaker> not sure it will barf or not
14:57:29 <Ammler> same issue with default
14:57:40 <Ammler> just there it is sprite 3032
14:57:54 <andythenorth> I just call nmlc on something?
14:58:02 <Ammler> andythenorth: you don't need to use older nml or ogfx
14:58:12 <Ammler> the issue is everywhere :-(
14:58:25 <andythenorth> well let me test now I'm on 0.2 and 0.4
14:58:34 <Ammler> planetmaker: what nml does ogfx default use?
15:00:41 * andythenorth wonders which switches nml needs
15:03:15 <andythenorth> nmlc --grf=ogfxe_extra.nml ?
15:05:21 <andythenorth> it's funny, I can't find an example in docs or tutorial
15:05:43 *** TWerkhoven has joined #openttd
15:06:43 <andythenorth> make: *** No rule to make target `Makefile.dep', needed by `ogfxe_extra.grf'. Stop.
15:07:54 <planetmaker> Ammler, nml trunk
15:08:06 <Ammler> maybe you need at least once to run make without target
15:08:17 <peter1138> has jupix twigged yet?
15:08:18 *** welterde has joined #openttd
15:08:19 <planetmaker> andythenorth, probably you'll need simply run make w/o any frills
15:08:25 <Ammler> or is that missing dep script?
15:08:58 <planetmaker> Ammler, probably that's missing the dep. yes
15:09:06 <Ammler> planetmaker: according to devzone, the issue exists on ogfx nightly too
15:12:33 <Ammler> I used 0.4 because that is what I have on the obs and run on different distros
15:19:29 * andythenorth has lost grf2html
15:20:04 <Ammler> you should be able to run the one from tt-forums
15:20:08 <andythenorth> you've verified this exists without gr2html?
15:20:30 <andythenorth> could be grf2html in that case
15:20:33 <Ammler> with py2.7, those sprites are empty 0,0
15:20:48 <andythenorth> unlikely to be grf2html of course
15:20:49 <Ammler> with < 2.7 those are the ugly random sprites
15:21:30 <Ammler> the md5sum is different
15:21:53 <andythenorth> is the extra stuff a 'normal' grf or base set?
15:21:57 * andythenorth is trying to test in game
15:22:47 <andythenorth> I'll get grf2html
15:22:53 <Ammler> if you change the grfid, I guess, you could add it as newgrf
15:23:58 <Ammler> I wonder, nobody misses those sprites yet
15:24:31 <andythenorth> compile required
15:25:21 <Ammler> andythenorth: we do not need confirmation, we know there is an issue
15:25:29 <Ammler> we need to know, how to fix it :-)
15:26:05 <andythenorth> it's likely PIL, but that is quite a big assumption
15:26:47 <Ammler> I would bet a lot against :-P
15:26:53 <andythenorth> I can't verify that I have the issue locally
15:27:12 <Ammler> andythenorth: run md5sum
15:27:27 <Ammler> and compare with the release
15:30:18 <Ammler> looks like the version is bound to python?
15:30:35 <Ammler> python 2.7 and pil 1.1.7, python 2.6 and pil 1.1.6?
15:31:18 <Ammler> I have no older distro with working nml here
15:31:45 <Ammler> but pm tested with 2.5, planetmaker what pil do you have?
15:33:10 * Ammler still waits for andythenorth enlighten idea :-)
15:33:22 * andythenorth is still trying to verify issue
15:33:46 <Ammler> use the java from tt-forums
15:33:48 <andythenorth> where is md5 sum for release of 0.4 branch of ogfxe_extra.grf?
15:34:03 <andythenorth> grf2html has no mac release
15:34:06 <andythenorth> and won't compile
15:34:15 <andythenorth> it's crashing under WINE
15:34:50 <andythenorth> I should build 0.4.1 branch?
15:34:50 <Ammler> yes, as the filename shold tell
15:34:58 <Ammler> well, did you test with nightly?
15:35:11 <Ammler> there is no switch in hg :-P
15:35:24 <andythenorth> there is hg up though :P
15:35:48 <Ammler> andythenorth: you need to built a version you can compare with devzone
15:35:56 <Ammler> it would also fail with nightlies
15:36:41 *** TGYoshi has joined #openttd
15:38:34 <Ammler> the issue is also that there isn't a single md5sum for the old distros, it has random sums
15:39:14 <Ammler> so we are kinda lucky, the newer distro (openSUSE_Tumbleweed in this case) does skip those ugly sprites
15:39:39 <Ammler> so it does at least on openSUSE and Fedora build the same
15:39:51 <Ammler> and the LTS distros fail
15:41:51 <Ammler> but every failed distro has another md5sum
15:48:09 <andythenorth> md5s don't match for some items in r905
15:51:34 * andythenorth has PIL 1.1.7 with python 2.6.1
15:51:44 <andythenorth> but why opengfx?
15:51:49 <andythenorth> why not FIRS or other sets?
15:52:06 <andythenorth> is it a predictable set of images being corrupted?
15:53:07 <planetmaker> that's the questions which need answers
15:54:13 <Ammler> andythenorth: I see at least 4 sprites with grf2html
15:54:40 * andythenorth wonders why some of the src pngs are 299.999 DPI
15:54:46 <andythenorth> instead of 72 DPI
15:55:17 <Ammler> you find some issues on the river sprites?
15:55:49 <andythenorth> probably doesn't
15:57:04 <andythenorth> it's certainly not necessary to have ~300 DPI pngs though
15:57:24 <Ammler> how can a png care about DPI at all?
15:57:50 <andythenorth> I'm not sure it does
15:57:57 <andythenorth> might just be photoshop being odd
15:58:02 <andythenorth> or metadata in the png
15:58:13 <andythenorth> I doubt it's significant anyway
15:58:53 <Rubidium> for openttd/grfcodec dpi doesn't matter at all
15:59:14 <Ammler> well, you are the artist, you used the words "~300 DPI pngs"
15:59:25 <Ammler> that doesn't make sense to me :-)
15:59:38 <Rubidium> it's a somewhat stupid conversion scale
15:59:45 <Rubidium> though basically everything ignores it
16:00:07 <Ammler> yes, it could matter for printing or screens
16:00:40 <Ammler> maybe it is a metadata to tell how you should print it?
16:01:19 <Rubidium> and even there it's rarely used
16:01:34 <Rubidium> either you want it full page, or fit something, but rarely it's the dpi from the image
16:01:52 <Rubidium> dpi is really a bogus value
16:02:05 <Ammler> and doesn't mac and pc screens have different DPI? 72 and 96?
16:02:24 <Ammler> but that might be gone with hd
16:02:30 <Rubidium> or the dpi of a digital photo should be enormously high given the number of pixels per inch in the ccd
16:03:08 <Rubidium> my monitor is near 200 dpi, an old monitor not. Yet... every website I visit doesn't care
16:03:18 <Rubidium> all sizes of images are in pixels
16:03:33 <Ammler> ah, maybe that was something about fonts
16:06:07 <Ammler> planetmaker: I wonder, if nobody complains about missing sprites in the new opengfx, we might simply remove those 4 sprites, maybe those aren't needed?
16:06:46 <Ammler> doesn't grf have some directions, which aren't supported in openttd?
16:07:05 <andythenorth> wrt DPI, it's more that I wondered if it's a tell-tale from a particular program
16:07:22 <andythenorth> which might also be outputting pngs that PIL doesn't like
16:07:30 <andythenorth> but I don't like this kind of guesswork
16:08:04 <andythenorth> I could try batching all the pngs with photoshop, but I have no way to test for corruption
16:08:10 <Ammler> andythenorth: did you find pngs in rivers with different DPI?
16:08:37 *** TheMask96 has joined #openttd
16:08:38 <Ammler> could you paste a list?
16:08:52 <andythenorth> waterfeatures.png
16:08:56 <andythenorth> I'll check the others now
16:09:18 <Ammler> well, you need at least 2 to have difference :-P
16:09:18 <andythenorth> other pngs in the project have ~72 and ~96 DPI
16:09:59 <Ammler> and waterfeatures.png has?
16:10:28 <andythenorth> waterfeatures/riverrapids.png same
16:10:37 <andythenorth> there are a lot of files to check there :P
16:10:43 <Ammler> could you change it and provide a patch?
16:11:09 <Ammler> let me check, if I see DPI in gimp
16:11:19 <Rubidium> Ammler: in the resize window
16:11:34 <andythenorth> it's more likely that its related to the png output from the program used than the specific DPI
16:11:44 <andythenorth> unless 299.999 hits some edge case in PIL :P
16:15:16 <andythenorth> dunno if it helps
16:15:25 <andythenorth> worth at least eliminating this guess though
16:15:37 <Ammler> and building again, let's see :-)
16:15:44 <andythenorth> oh....time to make tea :)
16:17:30 <Ammler> so if that matters, it's at least not waterfeatures.png
16:17:41 <Ammler> but why should it matter just for one specific file :-)
16:18:55 <Ammler> gimp builds the same pngs on every distro
16:19:14 <Ammler> so how could it work just for 4 not?
16:19:35 * andythenorth is not good at this science
16:19:59 <Rubidium> Ammler: you confirmed the md5sum matched?
16:20:18 <Ammler> Rubidium: we run hg st on devzone
16:20:33 <Ammler> it would complain, if devzone builds other png as planetmaker uploaded
16:21:28 <Rubidium> so you also build the 4 failing distros on the devzone?
16:21:39 <Ammler> hg st 1>> ../%{name}/%{name}-%{version}-build.err.log 2>>../%{name}/%{name}-%{version}-build.err.log
16:21:42 <Ammler> [[ $(hg st -m) ]] && exit
16:22:16 <Ammler> Rubidium: no, but pm builds on very acient os
16:22:39 <Ammler> and he confirmed it fails on his os too
16:22:42 <Rubidium> but also with the same (ancient) gimp as is running on the 4 distros where things fail?
16:22:56 <Ammler> it doesn't make difference there
16:23:05 <andythenorth> what are the varying elements?
16:23:17 <andythenorth> we have no evidence of corruption elsewhere from different python versions
16:23:28 <planetmaker> ehm... python 2.5 with gimp 2.4 is not *that* outdated
16:23:54 <andythenorth> unless we find evidence in other grfs, it's reasonable to assume something is screwy with the input
16:23:59 <andythenorth> as that is main point of variation
16:24:18 <planetmaker> andythenorth, other grfs are not thoroughly tested in that respect
16:24:34 <planetmaker> I guess it'd never show, as they're only built by the devzone and maybe the author
16:24:43 <Ammler> I have same issue with opengfx build on systems without gimp
16:24:45 <planetmaker> but not by the opensuse CF for every distro there
16:24:50 <Rubidium> planetmaker: true, it's only OpenTTD 0.5-ish
16:25:03 <andythenorth> afaict, there's not much variation in PIL versions?
16:25:25 <planetmaker> the age of them, you mean?
16:26:09 <Rubidium> GIMP 2.4 is october 2007, Python 2.5 is September 2006
16:26:11 <Ammler> if gimp would be the issue, then it should fail on factory too, shoulndn't it?
16:27:01 <Ammler> and if gimp would be the issue, the DevZone would complain about pm's pngs
16:27:02 <Rubidium> depends on whether you mean gimp in general, or a particular subset of gimp instances
16:27:32 <Rubidium> but if rebuilding the pngs doesn't change them, then it's not the rebuilding that's the problem
16:27:57 <Rubidium> what happens when you emit nfo and build that with grfcodec?
16:28:04 <Rubidium> same corruption or not?
16:28:45 <Rubidium> if it's not corrupted, then there's something in the graphics code, otherwise there might be something wrong in the code that determines the location of the sprite
16:29:07 <Rubidium> alternatively you could disable cropping and see whether that yields corrupted grfs
16:29:37 <Ammler> well, the fact that it starts at sprite above 3000 excluded some generic thing, doesn't?
16:29:59 <MNIM> for some reason I read 'disable groping' and 'corrupted girls' in Rubidium's last line.
16:30:07 *** mahmoud has joined #openttd
16:30:31 <Ammler> we already excluded cropping irrc
16:30:43 * Rubidium advices a visit to the optician to MNIM
16:31:27 <Ammler> but cropping is also something which should cause issue below sprite 3000
16:32:44 <Ammler> I mean, it is fantastic, i can exactly say, which sprite causes the issue but have no clue how to find it in the source
16:33:21 <MNIM> more like a visit to the shrink
16:33:23 <Ammler> yep, that is how I know the sprite
16:33:25 <Rubidium> look up the sprite there, then you have a file image name
16:33:29 <MNIM> my mind is getting all freudian-like
16:34:26 <Ammler> planetmaker: we need target %.nfo :-)
16:35:28 <andythenorth> Ammler: what happens if you isolate these sprites in a new test grf?
16:35:41 <andythenorth> or swap the contents of the pngs for new contents?
16:36:45 <Ammler> andythenorth: I do not know, which png :-)
16:37:01 <Rubidium> anyhow, 3000 doesn't seem like a sensible magic number in any way to cause problems
16:37:07 <andythenorth> you have the sprite numbers?
16:37:13 <Ammler> Rubidium: it's 3033 or so
16:37:24 <Rubidium> and you have the nfo nml creates?
16:37:36 <Rubidium> which revision of opengfx?
16:38:44 <Ammler> sprites/png/terrain/waterfeatures/rivermouth_tropical_ne.gimp.png 241 97 01 23 64 -31 0
16:40:28 <Ammler> andythenorth: could you check that file?
16:40:42 <Rubidium> that's pretty out-of-bounds
16:41:11 <Rubidium> sprites/png/terrain/waterfeatures/rivermouth_tropical_ne.gimp.png: Error: Sprite y extends beyond end of the spritesheet.
16:41:14 <Rubidium> Spritesheet has 49 lines, sprite wants 97..119
16:42:50 <Rubidium> you understand the above output of grfcodec?
16:43:18 <Rubidium> so you just found two bugs ;)
16:47:12 <Ammler> but where the hell are those errors on devzone?
16:48:08 <Rubidium> that's the second bug ;)
16:49:25 <Ammler> now it would be interesting, why old distro handle it differently
16:49:38 <planetmaker> that's then probably a python thing
16:49:45 <Ammler> without -c, on newer it is a blue box
16:49:56 <Ammler> on older it is that random whatever
16:49:59 <planetmaker> which makes a sanity check possibly in PIL not doing an out-of-bounds reads, clamping values to the graphics size
16:50:00 <Rubidium> sounds like undefined behaviour
16:50:25 <Ammler> that explains, why we had the issue also without -c
16:51:04 <Rubidium> IMO nmlc should check whether the rectangle it wants to get is within the bounds of the image, if not: show a warning instead of silently continueing
16:51:13 <Ammler> planetmaker: why did it need so long until someone told me, I should make a nfo with nmlc :-P
16:52:06 <andythenorth> unusual problem?
16:52:19 <andythenorth> we're not used to hunting down these issues?
16:52:47 <Ammler> well, but finding a sprite in the nml source isn't that uncommon, is it?=
16:53:05 <Ammler> and this seems a reasonable way
16:53:33 *** bernardh has joined #openttd
16:53:38 <Ammler> planetmaker: and you were wrong with your guess, that it is temperate :-P
16:53:41 <Rubidium> it's basically the obvious way
16:54:04 <Rubidium> which is why I assumed you already done it in the many hours of backlog ;)
16:54:06 <bernardh> Hey, just wanted to say OpenTTD seems awesome and I have no idea why I've never heard of it before! n_n-b
16:54:30 <Ammler> I made the nfo with grfcodec
16:54:49 <Ammler> to find the difference on the grfs
16:55:14 <bernardh> And that my solution to playing in fullscreen and being able to read documentation on Linux is to run it in another X display. xD
16:56:03 <Ammler> bernardh: and you run it in fullscreen because?
16:56:22 <bernardh> Ammler, I like to use all of my display.
16:57:36 <Ammler> hmm, isn't it possible to switch window when openttd is in fullscreen?
16:57:41 *** andythenorth has left #openttd
16:57:45 *** andythenorth has joined #openttd
16:57:45 *** andythenorth has left #openttd
16:57:50 *** andythenorth has joined #openttd
16:58:08 <bernardh> Ammler, maybe with a strange window manager, or a patch to X11 that prevents keyboard grab. But xinit is easier.
16:58:50 <Ammler> well you might waste resources which you need in the game ;-)
16:59:59 <bernardh> Heh. The default blitter was pretty slow at 1920x1080, but 32bpp-optimized seems fine. :D
17:00:40 <andythenorth> is it useful for a grf to list all vehicles in the docs?
17:00:51 <andythenorth> or does that spoil the surprise?
17:01:43 <Rubidium> bernardh: sadly enough it's not the blitter that's slow but probably your GPU (phyisical or driver) not having hardware acceleration anymore for paletted images
17:03:00 <bernardh> Rubidium, sad face. It's a GTS 450 with 1024 megs of VRAM with the proprietary drivers, which seems sufficient for most things. Not this, apparently. =D
17:03:19 <bernardh> Maybe it's just the opening menu thingie.
17:03:38 <bernardh> I didn't try a game with the default, as the mouse wasn't even moving smoothly.
17:03:53 <Rubidium> the newer the hardware, the worse the support for 8bpp paletted images
17:05:01 * bernardh googles paletted textures furiously
17:05:46 <bernardh> I didn't even know you could do that without shaders. Nifty.
17:07:23 <bernardh> Rubidium, like I said. I'm simultaneously pleased that you can do that and disappointed that it's being phased out.
17:10:45 <planetmaker> 18:00 andythenorth: is it useful for a grf to list all vehicles in the docs? <-- IMHO yes
17:15:16 <andythenorth> planetmaker: txt or html with images?
17:15:32 <planetmaker> readme.txt, so users can also see it ingame :-)
17:15:48 <planetmaker> And get possibly additional info on history etc
17:15:52 <planetmaker> Would fit very well there
17:17:26 *** Prof_Frink has joined #openttd
17:24:00 *** TheMask96 has joined #openttd
17:31:59 <andythenorth> better? less info? more?
17:32:04 <andythenorth> alignment I can fix later
17:37:42 *** Keyboard_Warrior has joined #openttd
17:39:01 *** Keyboard_Warrior has joined #openttd
17:43:41 *** holyduck has joined #openttd
17:50:50 *** Keyboard_Warrior has quit IRC
17:56:59 *** frosch123 has joined #openttd
18:00:46 *** Chris_Booth[ph] has joined #openttd
18:04:23 *** Chris_Booth has joined #openttd
18:05:19 *** FLHerne has joined #openttd
18:06:57 *** valhallasw has joined #openttd
18:11:53 <CIA-1> OpenTTD: frosch * r23917 /trunk/src/newgrf_cargo.cpp: -Fix (r11252,, r23914, r23915): Also use the CTT for refitmasks for version 6 GRFs. I.e. fix the cursed GetCargoTranslation() function for the fourth time.
18:12:44 *** theholyduck has joined #openttd
18:12:56 <frosch123> not sure whether i counted right :p
18:13:43 <Rubidium> then use toomanieth time ;)
18:14:22 *** lollercaust has joined #openttd
18:15:20 *** Chris_Booth[ph] has quit IRC
18:16:12 <frosch123> interestingly the bugs never mattered as the function was never called with usebit = true before r23915
18:28:12 *** kkb110_ has joined #openttd
18:29:46 *** Biolunar has joined #openttd
18:36:41 *** lmergen has joined #openttd
18:44:01 *** Xrufuian has joined #openttd
18:45:12 <CIA-1> OpenTTD: translators * r23918 /trunk/src/lang/ (french.txt hungarian.txt):
18:45:12 <CIA-1> OpenTTD: -Update from WebTranslator v3.0:
18:45:12 <CIA-1> OpenTTD: french - 19 changes by OliTTD
18:45:12 <CIA-1> OpenTTD: hungarian - 4 changes by IPG
19:04:45 *** Brianetta has joined #openttd
19:08:05 *** Chris_Booth has joined #openttd
19:08:59 *** andythenorth has joined #openttd
19:10:08 *** HerzogDeXtEr1 has joined #openttd
19:17:49 * andythenorth contemplates what run cost algorithm should be
19:19:02 <andythenorth> best proxy for fuel cost is HP?
19:40:19 *** peteris has joined #openttd
19:41:12 *** Firartix has joined #openttd
20:06:08 *** TWerkhoven[l] has joined #openttd
20:09:46 *** JVassie has joined #openttd
20:10:00 *** welterde has joined #openttd
20:26:33 *** lmergen has joined #openttd
20:45:34 *** Keyboard_Warrior has joined #openttd
21:02:36 *** Chris_Booth has joined #openttd
21:06:20 *** andythenorth has joined #openttd
21:17:19 *** andythenorth has joined #openttd
21:21:25 *** Rhamphoryncus has joined #openttd
21:24:26 *** andythenorth has joined #openttd
21:24:56 *** FLHerne has joined #openttd
21:33:40 *** Progman has joined #openttd
21:37:08 *** andythenorth is now known as Guest1961
21:37:09 *** andythenorth has joined #openttd
21:46:52 *** Keyboard_Warrior has quit IRC
21:47:22 *** theholyduck has joined #openttd
21:58:56 *** andythenorth has joined #openttd
21:59:22 <andythenorth> seriously, 63.75t weight is not enough for RVs
21:59:33 <andythenorth> trains have up to 1279t
21:59:46 <andythenorth> but trains don't have to put the entire consist weight on the lead vehicle
21:59:50 <andythenorth> "just saying" ;)
21:59:55 *** andythenorth has left #openttd
22:10:28 *** Brianetta has joined #openttd
22:37:42 <FLHerne> When starting Chill's Patchpack, I get this error:
22:37:47 <FLHerne> dbg: [misc] [squirrel] Failed to compile '/home/francis/.openttd/content_download/ai/AIAI-iota3.tar/aiai-iota3/info.nut'
22:37:47 <FLHerne> Your script made an error: the index 'CONFIG_DEVELOPER' does not exist#
22:38:29 <FLHerne> Would this be because of the AI being newer than the nightly that the patchpack's based off
22:39:25 <planetmaker> or just not announcing its compatibility properly
22:40:37 <FLHerne> Any workarounds to that? The version of AIAI with railways looks quite good on the forums
22:41:27 <planetmaker> delete the AI locally
22:41:37 <planetmaker> but you can just ignore it, too
22:42:06 <planetmaker> after all it works well with other openttd versions as far as I know
22:42:34 <FLHerne> Well, it doesn't stop TTD running, but using the AI would be nice
22:43:02 <FLHerne> I can always use a different one :D
22:43:29 <planetmaker> Well. It's just a message which tells you that that AI won't work with that openttd version you use
22:48:54 *** swissfan91 has joined #openttd
22:50:15 <swissfan91> what is the definitive number of snow transitions that tiles can show?
23:44:20 *** bernardh has joined #openttd
23:47:29 <bernardh> Hi there! I can't get the music to work (Linux, PulseAudio). I have timidity installed and running, the .gm files from the original (I also tried with OpenMSX and the Joplin anthology). I'm running with the flag -m extmidi, timidity can play all the music. I've tried running both openttd and timidity with padsp, and all the sounds work besides.
23:50:48 <bernardh> I'll try the generic binaries on the site, see if they behave differently.
23:53:00 *** Cybertinus has joined #openttd
23:53:47 <bernardh> Yeah, that works fine. I'll see about getting a bug filed against the Arch package.
continue to next day ⏵
