Log for #openttdcoop.devzone on 23rd October 2012:
Times are UTC Toggle Colours
04:56:45  <Brot6> zBase - Bug #4433 (New): Missing sprites after rebuild XRubidiumX @
06:40:19  *** Zuu has joined #openttdcoop.devzone
07:24:56  *** Zuu has quit IRC
07:55:51  *** Nat_aS has quit IRC
07:55:54  *** Nat_aS has joined #openttdcoop.devzone
09:34:46  <V453000> is it possible to make a newGRF which would override a flag for all vehicle IDs?
10:09:10  <Yexo> no
10:13:04  <V453000> thought so, thanks
11:58:48  *** KenjiE20 has quit IRC
13:24:23  *** andythenorth has joined #openttdcoop.devzone
13:24:40  <andythenorth> so how would zBase style sprites be added to FIRS?
13:24:47  <andythenorth> I have read none of the specs on 32bpp stuff
13:24:56  <andythenorth> not planning to right now either :)
13:24:56  <andythenorth> 
13:25:46  <andythenorth> I figure it's just extra spritesets or something?
13:29:41  <Rubidium> first step would be getting them rendered with blender and using the construction Zephyris has made for them. The rest is 'just' coding some alternative sprites
13:30:03  <Rubidium> SELECT CustomerID
13:30:03  <Rubidium> FROM GeographicEdge
13:30:03  <Rubidium> WHERE ModelID = 3
13:30:03  <Rubidium> GROUP BY CustomerID
13:30:10  <Rubidium> argh...
13:30:14  <Rubidium> stupid putty
13:33:46  <andythenorth> so Zeph is going to supply some sprites
13:34:15  <andythenorth> like these
13:49:36  <Terkhen> looks nice :)
13:54:46  <andythenorth> needs someone to extend the FIRS templates... o_O
14:00:41  *** andythenorth has quit IRC
14:33:59  *** andythenorth has joined #openttdcoop.devzone
15:01:28  *** ODM has joined #openttdcoop.devzone
15:10:08  *** ODM has quit IRC
15:13:25  *** ODM has joined #openttdcoop.devzone
15:44:59  <Terkhen> andythenorth: does zoom works with switches too? I thought it used the sprites for different zoom levels as a single one somehow
15:45:16  <andythenorth> dunno :)
15:55:03  <Rubidium> the 32bpp and/or extra zoom sprites will be alternative sprites to the 8bpp normal zoom sprite
15:55:58  <Rubidium> you cannot have 32bpp and/or extra zoom sprites without a 'corresponding' 8bpp normal zoom sprite
15:56:53  <Rubidium> look at e.g. near the end
15:57:32  <Rubidium> the base_graphics will be equivalent to the current your sprites/sprite templates, the alternative sprites will provide the different graphics for that sprite
15:58:22  <Rubidium> zbase_extra.nml has more templates
16:05:11  *** frosch123 has joined #openttdcoop.devzone
16:08:25  <Terkhen> Rubidium: I see, thanks :)
16:19:34  *** andythenorth has left #openttdcoop.devzone
16:40:16  <Ammler> woudn't it be easiest to create a zFIRS repo and then make FIRSbuild which has firs and zfirs like opengfx and zbase ?
16:41:41  <planetmaker> nah, I think it should be one repo in this case, Ammler
16:42:12  <planetmaker> as here it's the very same project. Could be for zBase / OpenGFX, too. From now on... sort-of
16:42:18  <planetmaker> history ;-)
16:42:43  <Ammler> so let devzone build the renders too?
16:43:31  <planetmaker> no. Add the rendered sprites to the repo. Rendering takes too long
16:43:55  <Ammler> but where do you save the blend files?
16:44:12  <Ammler> like gimp stuff?
17:04:07  *** Alberth has joined #openttdcoop.devzone
17:21:02  <Brot6> firs: update from r3057 to r3060 done (3 warnings) -
17:33:50  <planetmaker> same project
17:35:18  <Alberth> 'oi
17:43:15  *** KenjiE20 has joined #openttdcoop.devzone
18:11:06  *** Zuu has joined #openttdcoop.devzone
18:12:30  *** andythenorth has joined #openttdcoop.devzone
18:30:04  <Rubidium> rendering zbase only took 515 minutes
18:30:18  <Rubidium> now it's working on making the 8bpp mask sprites
18:32:57  <Rubidium> only massive caveat is that I didn't get exactly the same PNGs as Zephyris did
18:33:07  <Rubidium> some were the same, some weren't
18:41:42  <Alberth> weird
18:44:20  <Ammler> could be because zeph modified the renders?
18:46:19  <Ammler> "These are some scripts to help with automatic pixel tweaking of graphics."
19:13:16  *** Alberth has left #openttdcoop.devzone
19:16:36  *** andythenorth is now known as Guest2904
19:16:37  *** andythenorth has joined #openttdcoop.devzone
19:23:49  *** Guest2904 has quit IRC
19:28:48  <frosch123> <- yay, that was fun exploring!
19:28:49  <Webster> Title: Transport Tycoon Forums View topic - GRFCodec 6.0.1 (at
19:38:36  *** andythenorth has quit IRC
19:39:00  *** andythenorth has joined #openttdcoop.devzone
20:19:09  *** andythenorth has left #openttdcoop.devzone
20:43:27  <Rubidium> Ammler: possibly, but then we really need to figure out what needs to be done exactly and how, so anybody can rebuild zbase correctly
20:43:39  <Rubidium> it might also be something specific to the blender version or so
20:45:20  <Ammler> well, would be nice to setup a Makefile
20:46:09  <Ammler> ImageJ can be made available
20:46:29  <Rubidium> the makefile currently is somewhat tricky
20:46:48  <Rubidium> a proper makefile knows what files are going to be generated, however we do not know that
20:47:03  <Rubidium> thus it cannot see when it needs to rebuild stuff and/or what gets rebuilt
20:47:35  <Rubidium> I fear it ends up being completely generated from the already existing output
20:47:48  <Rubidium> including the 8bpp mask files
20:48:20  <Rubidium> for you'd do a find for pngs, determine the .blend (which is directory name of png + .blend) you can generate that part
20:48:47  <Rubidium> for the 8bpp mask file you search for the mask files and depend on the same file a folder up, which gets processed using imagej
20:49:06  <Rubidium> currently the imagej script asks the user, via a GUI, for the folder to process
20:50:39  <Rubidium> and that script seems horribly slow (if I'm running the right one actually)
20:51:15  <Ammler> 5 hours aren't that awuful long
20:51:41  <Rubidium> imagej has ran for 5 hours now
20:51:42  <Ammler> so IMO, it could be included to the build jobs
20:52:31  <Ammler> ok, so 515 mins to render, anohter min. 5 hours for imagej?
20:52:40  <planetmaker> uhm... I surely don't want a 5 hour daily build job
20:53:41  <Rubidium> Ammler: 5 hours for 2000 sprites
20:53:55  <Rubidium> and another 10-12k to go
20:54:21  <Rubidium> 515 minutes => 10 hours
20:54:45  <Ammler> yeah, far more than 5h :-)
20:55:37  <Rubidium> I'd say 2d is a better estimate
20:55:43  <Ammler> :-)
20:56:54  <Rubidium> hmm
20:57:25  <Rubidium> 312m, 1001/11699
20:57:42  <Rubidium> @calc 1001/11699*312/60
20:57:42  <Webster> Rubidium: 0.44492691683
20:57:51  <Rubidium> @calc 1001/11699*312/60*100
20:57:51  <Webster> Rubidium: 44.492691683
20:57:56  <Yexo> a daily 44-hour job :)
20:57:59  <Rubidium> ouch...
20:58:03  <planetmaker> hehe
20:58:05  <Rubidium> imagej seems slow ;)
20:58:08  <frosch123> daylength patch!
20:58:21  <planetmaker> maybe we should move to venus or mercury
20:58:27  <planetmaker> but not to mars or jupiter
20:58:38  <^Spike^> ....
20:58:39  <Ammler> I already think, days are too short, so let us fix this issue first :-)
20:58:40  <planetmaker> hm. The moon would suffice actually
20:58:44  <Rubidium> so 2 days for imagej, half a day for blender and a bit for nml. So 60 hours?
20:59:01  <Rubidium> the so-called zbase weekendly
20:59:06  <planetmaker> :D
20:59:18  <Yexo> what do we do about grfcodec? 1) simply revert the change, 2) make it a command-line option to turn on/off (with what default?), 3) leave it as it is
20:59:19  <frosch123> planetmaker: is a moon-day based on seeing the earth or seeing the sun?
20:59:49  <frosch123> Yexo: maybe only do it for container 2
20:59:58  <planetmaker> day is defined as the time between sunrise and sunset
21:00:12  <Yexo> that's a good other option indeed
21:00:51  <planetmaker> frosch123, Yexo what I didn't get... if the code is used since 2002 - how can he have gotten a working grf with grfcodec 5.0?
21:00:54  <^Spike^> i suggest making that 2 sunrises and sunsets... :)
21:01:10  <frosch123> planetmaker: decoding since 2002, encoding since 2012
21:01:14  <Yexo> planetmaker: it isn't used since 2002, it was implemented for "decoding" since 2002
21:01:27  <planetmaker> oh, I missed that part, I guess
21:02:22  <frosch123> likely someone (patchman?) misread ttd asm code, wrote a incorrect decoding (which was never triggered), and later someone updated the grf description to match what grfcodec did
21:02:26  <Rubidium> frosch123: seems like days are defined in three ways: stellar day (rotation in comparision to distant stars), sidereal day (compared to vernal equinox) and mean solar day (rotation compared to central star)
21:03:11  <planetmaker> ^^ :-)
21:03:35  *** ODM has quit IRC
21:03:38  <planetmaker> USS enterprise, captain's log, star date 4293.54
21:03:41  <planetmaker> or so ;-)
21:03:55  <frosch123> Rubidium: so there is no definition which defines the rotation of the moon around its planet? or has really *every* moon stopped that rotation?
21:04:36  <planetmaker> frosch123, that's a month ;-)
21:04:47  <frosch123> i mean from the other pov
21:05:18  <planetmaker> frosch123, the earth will turn several times while you see it... and no, there's no special name for that afaik
21:05:20  <frosch123> a month is more like a moon year
21:05:23  <Rubidium> frosch123: wikipedia doesn't list it ;)
21:05:36  <Rubidium> so, how am I supposed to know?
21:05:44  <planetmaker> frosch123, not really... unless you mean with "year" the revolution around Earth
21:05:44  <frosch123> well, it's quite infinitish for earth moon
21:06:08  <planetmaker> Which technically is not even around earth. If you look at Earth's and Moon's ellipses around the sun, the moon's ellipse never bends outwards either ;-)
21:06:14  <Rubidium> planetmaker: more like stardate -300000
21:06:51  <frosch123> planetmaker: a earth day is the time the earth needs to turn around itself to face the sun in the same direction again; a earth year is the time the earth needs to move around the sun
21:07:07  <Brot6> FIRS Industry Replacement Set - Revision 3061:dadd30d534e0: Feature: snow for Lumber Yard (mostly co... XandythenorthX @
21:08:14  <frosch123> so, a moon day is the time the moon needs to turn around itself to face the earth in the same direction (near infinite), and a moon year is the time the moon takes to move around the earth (maybe a month, but no idea)
21:08:27  <frosch123> does the definition of "year" include the rotation of the sun around itself?
21:08:53  <Brot6> firs: update from r3060 to r3061 done (3 warnings) -
21:09:03  <planetmaker> In my book a "year" usually refers to the revolution around the central star. Though it's tricky for moons
21:09:21  <planetmaker> the rotation of the sun around itself is irrelevant for the definition of the year
21:09:42  <planetmaker> (and it would be tricky, the sun is not a rigid rotator, but rotates with different speeds at different latitudes)
21:13:22  <planetmaker> frosch123, the main issue for a person living on the moon is: the sun would be more important there, too. So the definition of year and day probably would make more sense wrt sun there as well
21:14:11  <frosch123> so, the earth is the moon of the moon
21:14:12  <Rubidium> isn't the path the moon makes basically the same as the earth takes, except with a higher amplitude
21:14:53  <planetmaker> yes, that's right, Rubidium
21:15:15  <planetmaker> frosch123, in our special case you could call Moon+Earth nearly a binary planet ;-)
21:15:36  <Rubidium> yeah ;)
21:16:15  <Rubidium> what was it, the centre of gravity of 'earth' when comparing it to the sun is some 4000 km away from the centre of the earth
21:17:29  <planetmaker> it's only a factor of 70 in mass
21:18:38  <Rubidium> hmm...
21:18:45  <Brot6> FIRS Industry Replacement Set - Feature #1795: Lumber Yard needs snow graphics XandythenorthX @
21:18:58  <Rubidium> wouldn't that imply that during a new moon the temperature should be generally lower than during a full moon?
21:23:17  <frosch123> certainly :) the earth slightly more far away, the moon casts no lights onto the earth, and sometimes it even casts a shadow onto the earth
21:23:28  <frosch123> in the latter case it is noticeable colder
21:24:04  <Rubidium> Yexo: back to you question; maybe make it depend on GRF container v2? Does NML exclusively push container v2?
21:24:10  <Rubidium> (NML tip that is)
21:27:25  <frosch123> v2 is likely the best option
21:27:34  <frosch123> adding an extra option feels quite pointless
21:27:42  <frosch123> and just dropping is too sad :)
21:28:00  <frosch123> also, for 32bpp sprites it might have a bigger impact anyway, since there is more stuff to compress
21:30:37  <Brot6> FIRS Industry Replacement Set - Revision 3062:aa1cc8a89dd2: Codechange: convert CPP ids to python in... XandythenorthX @
21:30:37  <Brot6> FIRS Industry Replacement Set - Revision 3063:1c023a3942c3: Feature: finished snow for lumber yard (... XandythenorthX @
21:30:37  <Brot6> FIRS Industry Replacement Set - Feature #1795 (Closed): Lumber Yard needs snow graphics XandythenorthX @
21:32:25  <Brot6> firs: update from r3061 to r3063 done (3 warnings) -
21:44:48  <frosch123> night
21:44:51  *** frosch123 has quit IRC
21:44:58  <Ammler> Rubidium: you mean nml default :-P (never use tip as version)
21:47:14  <planetmaker> default is no version. tip is
21:47:42  <Ammler> now, that is just lol, you still don't get it
21:48:22  <Ammler> the whole day we once discussed that and you learned nothing
21:49:59  <Ammler> well, good night then ;-)
21:50:51  <Ammler> such statement proves it even more, webgui should get rid of "tip"
21:54:06  <planetmaker> <-- which is your version "hg default"?
23:20:43  *** Zuu has quit IRC

Powered by YARRSTE version: svn-trunk