Log for #openttdcoop.devzone on 8th August 2011:
Times are UTC Toggle Colours
08:03:17  <Brot6> FIRS Industry Replacement Set - Revision 2237:7f1d10be121a: Cleanup: Remove unused and unneeded t... (planetmaker) @
10:17:14  <Terkhen> planetmaker:
10:19:01  * planetmaker reads
10:19:18  <Terkhen> check only the first one, the rest are simplifications :P
10:20:31  <Hirundo> Does that work? *doubts*
10:20:41  <planetmaker> why not?
10:21:06  <planetmaker> I think it's ok, Terkhen
10:21:16  <Hirundo> Adding a spriteset to a number tends to ... well.. not work :)
10:21:23  <Terkhen> I have only tested that it compiles
10:21:40  <Terkhen> hmm... how is the correct way to give a spriteset an offset then? I understood you wrong :P
10:21:43  <planetmaker> I'm just pondering whether the macro name could be changed, but I have no better idea, esp. given the simplifications
10:21:59  <planetmaker> Terkhen, spriteset(number)
10:22:04  <planetmaker> references the n-th sprite
10:22:07  <Terkhen> ok, I'll change it :)
10:22:13  <planetmaker> good point, Hirundo :-)
10:22:20  <planetmaker> I'm still in the post-lunch coma ;-)
10:22:28  <planetmaker> I returned 5 mintues ago :-P
10:22:42  <Hirundo> I wonder.... how it compiled then *tests*
10:23:43  <Terkhen> Block 'name' is not referenced, ignoring... <--- depends on how much attention it pays to it once it is not referenced :P
10:24:23  <Terkhen> <--- this is the expanded code
10:24:45  <Terkhen> as ugly and ilegible as I could make it :P
10:25:13  <planetmaker> :-)
10:25:38  <Terkhen> I thought about adding a comment to the macro, but of course the preprocessor removes it :P
10:26:01  <planetmaker> sprite: spriteset_2686(terrain_type == TILETYPE_DESERT) + 2 * (... )
10:26:24  <Terkhen> yes, I'm correcting it
10:26:34  <Terkhen> I pasted that code just in case Hirundo wants to test :P
10:26:40  <planetmaker> aye
10:27:09  <Hirundo> upon trying to compile, I did get the error I expected
10:27:14  <Hirundo> so the world is still fine :P
10:28:01  <Terkhen> ok :)
10:28:08  <Terkhen> it just ignores the error if the block is not referenced then
10:28:21  <Terkhen> hmm...
10:28:53  <Terkhen> is it possible to make spritesets with sprites such as GROUNDSPRITE_CONCRETE?
10:29:40  <planetmaker> hm... ttdsprites?
10:29:45  <planetmaker> they're numbers
10:29:56  <Hirundo> not unless you duplicate either duplicate those sprites, or allocate your own groundsprites via GRM
10:30:02  <planetmaker> of course one can explicitly include those sprites, but that'll break with base set differences
10:31:16  <Terkhen> there goes my template :(
10:31:22  <Hirundo> GRM (builtin function reserve_sprites() in NML) will work, but it's not recommended for large amounts of sprites
10:31:46  <Terkhen> I'll just add three parameters for ground
10:32:20  <Hirundo> mind that all spritesets used in a single spritelayout need to have the same sprite count
10:34:54  <Terkhen> I suppose that all sprites from a spriteset also need to come from the same file
10:35:28  <Hirundo> Not necessarily
10:35:44  <Hirundo> You can add a filename as 7th or 8th parameter to the real sprite
10:37:18  <planetmaker> bah... how can a guy like Nekomaster be around that long and not know the very basics of where to post and what to report. Stupid as straw is an euphemism...
10:37:36  <Hirundo> Now I remember... IIRC there is some obscure bug(ette) in ottd's handling of construction stages
10:37:46  <Terkhen> oh, ok :)
10:39:09  <Hirundo> I thought I had reported that, but Flyspray tells me otherwise and is most probably right
10:39:44  <Terkhen> planetmaker: the key to happiness in online communities is a big ignore list
10:40:01  <planetmaker> well... but possibly it's a valid bug report
10:40:09  <planetmaker> thus I wouldn't want to ignore it
10:40:23  <planetmaker> besides that: you're right :-)
10:40:28  <planetmaker> Though it works badly in the forums
10:40:37  <Terkhen> you can still display the messages if you want to
10:40:50  <Terkhen> sometimes I display Nekomaster's messages
10:40:53  <planetmaker> I know. I used it for a time, but I found that even more annoying ;-)
10:41:01  <Terkhen> at least lately he's not being rude to everyone
10:41:09  <Terkhen> which was the cause for the ignore in the first place
10:42:09  <planetmaker> well, indeed, the crash.log shows no suspicious newgrf activity
10:42:18  <planetmaker> and is from clean 1.1.1
10:44:33  <planetmaker> But still might be somewhat broken NewGRF...
10:45:01  <Brot6> HEQS "Heavy Equipment" Set - Bug #2945 (New): Railmotor in wrong group (andythenorth) @
10:45:02  <Brot6> HEQS "Heavy Equipment" Set - Bug #2946 (New): The Forklift changes to the "1950" model in the y... (andythenorth) @
10:45:11  <Terkhen> a broken NewGRF should not crash OpenTTD
10:46:04  <planetmaker> yes
10:46:29  <planetmaker> I agree. Still it might cause this one. In which case there's two bugs, one in OpenTTD one in the NewGRF ;-)
10:46:40  <Terkhen> hmm... andy is not here
10:46:43  <planetmaker> a true case of cooperation ;-)
10:47:03  <Terkhen> :P
10:47:53  <planetmaker> <--- uhm, is it just me, or are there three completely pointless lines of code?
10:49:18  <Terkhen> it should not be passing beyond the not reached, yes
10:49:48  <planetmaker> well, it doesn't. That NOT_REACHED() is triggered
10:50:16  <Hirundo> so the NOT_REACHED() works :)
10:50:26  <planetmaker> :-P
10:51:26  <Terkhen> it's strange though
10:51:46  <Terkhen> the comment seems to hint that those lines should be executed under some conditions
10:52:02  <planetmaker> and if not they have no right to exist
10:52:21  * planetmaker thinks that the NOT_REACHED() might actually mean to be below them...
10:53:13  <Terkhen> can I define multiple ground sprites and use hide_sprite to choose which one to draw?
10:54:07  <planetmaker> I guess so
10:54:25  <planetmaker> you can even draw several, e.g. when there are transparent overlay parts
10:54:41  <planetmaker> (also when not, but then it's pointless)
10:55:06  <Terkhen> ok, that simplifies things :)
10:55:27  <Terkhen> I'm going to install a VM before continuing though, compiling to test takes too much time and I'm asking too many questions :)
10:56:50  <planetmaker> :-)
10:57:00  <Hirundo> No, there can only be one ground sprite
10:57:37  <Terkhen> hmm
10:57:59  <Terkhen> then I can't unify spritelayouts unless I redefine the "base" sprites in spritesets
11:01:02  <Terkhen> I need the same spritelayout to use either GROUNDSPRITE_CONCRETE or GROUNDSPRITE_SNOW depending on the terrain... if that's not possible I can't unify :P
11:01:43  <planetmaker> uhm... but you can?
11:01:58  <Terkhen> nmlc: "sprites/nml/industries/food_market.pnml", line 13: Sprite layout can have no more than one ground sprite
11:02:14  <planetmaker> sprite: (terrain_type == XYZ) ? GROUNDSPRITE_XYZ : GROUNDSPRITE_SNOW
11:02:29  <planetmaker> interesting... I thought it could. Make the additional ones as child sprites
11:02:35  <planetmaker> that's probably what I did :-)
11:02:40  <Terkhen> operator ? can't return sprites
11:02:56  <planetmaker> but numbers... and ttdsprites are numbers
11:03:01  <Terkhen> oh :)
11:03:09  <planetmaker> like GROUNDSPRITE_SNOW = 4550 or so
11:03:15  <Terkhen> but then the template will not work if you pass sprites to it, and some cases require that
11:03:24  <planetmaker> that's true. But you cannot unify that
11:03:35  <planetmaker> at least I see no real way...
11:03:36  <Terkhen> well, that's the whole point of the template :P
11:03:59  <Terkhen> I did not think about using childsprites for this... aren't they drawn over the building sprite?
11:04:04  <planetmaker> what I'd try is: draw always a ttd ground sprite
11:04:15  <planetmaker> draw conditionally a custom sprite as childsprite to the ground sprite
11:04:28  <planetmaker> it could completely overdraw the ttd groundsprite
11:04:33  <planetmaker> draw the building sprite
11:04:54  <Terkhen> ok, let's try that :)
11:05:05  <planetmaker> I think the order matters. Thus ground->child->building works. At least that's what worked for me so far
11:05:12  <planetmaker> iirc I did that in ogfx+airports
11:05:20  <planetmaker> and possibly ogfx+industries
11:07:03  <Brot6> repository /home/hg/ai-aivehicletest registered in Redmine with url /home/hg/ai-aivehicletest
11:07:03  <Brot6> repository /home/hg/ai-aivehicletest created
11:11:46  <Terkhen> <--- this code works as expected, thanks :)
11:16:36  <planetmaker> Terkhen, but that seems unnecessary. Both are ttdsprites and could be swapped the ? operator
11:16:50  <Terkhen> other spritelayouts use spritesets
11:16:58  <Terkhen> for those, ? does not work
11:17:22  <planetmaker> yes... ?
11:18:21  <Terkhen> if you use (terrain_type == val) spriteset_1 ? spriteset_2, NML will complain because they are not integer
11:18:24  <Terkhen> integers*
11:18:35  <Terkhen> oops, that was completely wrong
11:18:39  <Terkhen> but I hope you understood what I mean
11:18:47  <planetmaker>
11:19:01  <Terkhen> internal server error
11:19:15  <planetmaker> actually sprite: custom_sprite_set(n) where n is whatever :-)
11:19:19  <Terkhen> but devzone works fine
11:20:06  <Terkhen> there, after deleting cookies it works
11:20:23  <planetmaker> hm, this cookie thingy sucks
11:20:40  <Terkhen> planetmaker: how do you template that code when you don't know if the parameter will be a ttdsprite or a spriteset?
11:21:23  <planetmaker> always ask for both and assume a default custom_sprite_set value which is interpreted as "not include"
11:21:56  <planetmaker> it has the side effect that also overlay "ground" sprites immediately work ;-)
11:22:38  <Terkhen> this is a macro, I can't do conditional code on it
11:22:46  <Terkhen> also, I don't understand why that would not work with the following code
11:22:54  <Terkhen>
11:23:10  <Terkhen> (I still have not checked it so it might have errors)
11:24:13  <planetmaker> hm, no "if" in a macro? Then indeed my suggestion doesn't work. Unless ... we define a 1px transparent sprite as default custom sprite :-)
11:24:45  <planetmaker> I think yours will also work, but no overlay ground sprite for temperate
11:25:39  <Terkhen> if that is needed later, it can be added as an additional template
11:25:54  <planetmaker> ok :-) Then go for the pasted solution for now
11:37:28  <Terkhen> <--- example code with this template
11:37:43  <Terkhen> most of the reduction is caused by removing dummy relative_pos and layout switch blocks
11:38:04  * Terkhen codes a bigger example
11:39:48  <Hirundo> Terkhen: I'd recommend PALETTE_USE_DEFAULT instead of 0 as palette
11:40:30  <Terkhen> ok :)
11:40:45  <Hirundo> Also I don't know how necessary the parametrized zextent is, as 16 is already the default
11:41:16  <Terkhen> it is not required in this case, but many other spritelayouts use a custom zextent
11:41:22  <Terkhen> the food market is small :P
11:41:40  <Hirundo> having a zextent that is too large doesn't hurt AFAIK
11:44:56  <planetmaker> it dirties a too large area needlessly afair
11:45:39  <Hirundo> yes, I see now
11:45:42  <Hirundo> better leave it this way :)
11:47:49  <Terkhen> hmm...
11:48:09  <Terkhen> nml allows templates? I'm checking sprite_templates.pnml
11:48:19  <Terkhen>
11:48:42  <Terkhen> ah, only for real sprites :)
11:48:43  <planetmaker> it does allow that. Check out ogfx+airports
11:49:47  <Terkhen> nice :)
13:19:52  <Terkhen> it is quite possible that some of the "extra" buildings some industries use can be templated too
13:20:01  <Terkhen> for example, the aluminium plant uses them for smoke
13:20:17  <Terkhen> at first glance, other industries use the same extra buildings in the same sequence with the same parameters for smoke
13:20:30  <Terkhen> for now I'll let them be
13:22:50  <planetmaker> yup
13:23:02  <planetmaker> smoke is animated, so that'll need to be somewhat special anyway, I guess
13:23:29  <planetmaker> thus maybe an "animated template"... but maybe not :-)
13:23:58  <planetmaker> a template used once is more confusing than helping
13:24:05  <planetmaker> *only once
13:27:40  <Terkhen> the smoke is done by just a animation_frame switch and a spritelayout that is duplicated N times, one time for each smoke animation
13:28:01  <Terkhen> therefore I'm thinking on a template that writes the duplicated spritelayouts for you
13:28:12  <Terkhen> it would receive the same parameters as the normal spritelayout templates
13:28:24  <planetmaker> uhm... duplicated sprite layouts?
13:28:34  <planetmaker> That's IMHO a case for a parameter to the sprite layout
13:28:38  <Terkhen> oh
13:28:42  <Terkhen> indeed :P
13:29:07  <Terkhen>
13:29:10  <Terkhen> that is the relevant code
13:29:18  <Terkhen> in theory I guess that we could make a single spritelayout
13:29:53  <Terkhen> and just hide the buildings depending on animation_frame
13:30:12  <planetmaker> that's what I'd do, indeed
13:30:31  <planetmaker> if needed, make use of a bit temporary storage, but I guess it's not needed as variables are directly accessible
13:30:40  <planetmaker> and no complex calculations
13:31:25  <planetmaker> if you want it easy, add a switch before which translates anim_frame_next to the actual sprite number
13:31:38  <planetmaker> (or so I'd do)
13:31:51  <planetmaker> But you now dealt with sprite layouts more than I :-)
13:33:28  <Terkhen> hmm... that would allow to store the sprite number
13:33:29  <planetmaker> hm... actually: that switch in your example: I'd replace that by a call of the same spritelayout. But utilize it for exactly that: the translation anim_frame to sprite number... via STORE_TEMP and then LOAD_TEMP in the layout
13:33:34  <Terkhen> but they also have different zextent and so on values
13:33:49  <planetmaker> store that, too ;-)
13:34:39  <Terkhen> hmm... then the template can be just a big switch and a building block, nice :)
13:34:46  <Terkhen> I'll save this for later though
13:34:47  <planetmaker> yup
13:35:14  <Terkhen> for now I'll just template the spritelayouts without paying attention to their "extra" building
13:35:22  <planetmaker> I'm currently somewhat on the trip to use excessively temporary storage and only one layout ;-)
13:35:43  <Terkhen> once that everything is nice and unduplicated, the common parts will stand out and will be easy to spot and template too
13:35:44  <planetmaker> but somehow I needed to trigger the 255 switches are not enough for ASLs ;-)
13:36:00  <planetmaker> but luckily we now have 64k :-P
13:38:42  <Terkhen> isn't that less efficient than just defining all the layouts?
13:39:22  <planetmaker> I'm not entirely sure
13:39:47  <planetmaker> I find it better readable, though
13:39:57  <planetmaker> There's one layout - but it just uses different sprites.
13:40:19  <planetmaker> but... maybe that's a matter of perspective and I might disagree with me in 4 weeks ;-)
13:42:06  <Terkhen> <-- those are two random layouts from the fertiliser plant, I'd like to see a unified version that is also more readable :P
13:43:51  <planetmaker> well... not one layout for all tiles :-P
13:45:37  <Terkhen> :)
13:47:09  <planetmaker> USE_GENERIC_TILE_LAYOUT(a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z) :-)
13:47:27  *** andythenorth has joined #openttdcoop.devzone
13:47:32  <andythenorth> hola
13:47:41  <andythenorth> Ammler: what monitoring tools and such do you use?
13:47:49  <andythenorth> I have to make a list for a work reason
13:48:17  <planetmaker> we recently installed munin
13:48:32  <planetmaker>
13:48:34  <Ammler> not really a monitor tool
13:48:38  <Ammler> but nice
13:48:39  <Terkhen> hi andythenorth
13:48:40  <Ammler>  :-)
13:48:41  <planetmaker> well... logging?
13:48:46  <planetmaker> hi andythenorth
13:48:48  <andythenorth> falls under 'and such' :)
13:48:53  <andythenorth> munin is awesome
13:49:03  <Ammler> icinga is what we loog at also
13:49:03  <andythenorth> do you have any uptime tools or alert tools?
13:49:13  <Ammler> look*
13:49:25  <Ammler> andythenorth: not needed, we don't have such services
13:49:35  <Ammler> our tools works always
13:49:35  <planetmaker> well... not?
13:49:45  <andythenorth> Ammler: he
13:49:53  <andythenorth> bad science :P
13:50:02  <Ammler> well, we are good :-)
13:50:18  <Ammler> or we use right os maybe
13:50:24  <andythenorth> you assume your good
13:50:38  <andythenorth> you have no idea if your services flap for n hours per day :)
13:50:50  <Ammler> that is what munin can tell
13:50:51  <andythenorth> if you have no monitoring or alerts :P
13:51:08  <Ammler> but munin does not restart or such
13:51:12  <andythenorth> no
13:51:14  <Ammler> which might be good
13:51:20  <andythenorth> do you use supervisord or anything for that?
13:51:31  <andythenorth> auto-restart can be bad if it's too sensitive
13:51:32  <Ammler> no, we use linux
13:52:06  <Ammler> well, we have an issue that sometimes the server goes crazy
13:52:17  <Ammler> but nobody has a clue why exactly
13:52:30  <andythenorth> k thanks
13:52:36  <andythenorth> one more for my list (
13:52:41  <Webster> Title: Home - Open Source Monitoring (at
13:52:42  <andythenorth> bbl
13:52:43  *** andythenorth has left #openttdcoop.devzone
13:52:49  <planetmaker> andythenorth, you could ask tb or rb...
13:54:51  <Rubidium> pff... monitoring? How lame ;)
13:55:35  <Ammler> I more and more suspect our bundles server with the php script to be the issue of all our troubles
13:56:03  <Rubidium> not memory wasting python?
13:56:28  <Rubidium> and python trying too hard not to barf when at the memory limit
13:57:32  <Ammler>
13:58:15  <Ammler> specially the memory graph is interesting, sometimes when the cache "cleans", load average can go > 100
14:02:34  <Ammler> we use python mostly on devzone, where we have stady memory useage of around 1.5-2 GB
14:02:45  <Ammler> python runs with gunicorn
14:03:08  <Ammler> hgweb and paste (lodgeit)
14:04:31  <Ammler> hgweb needs 200mb, paste 50
14:41:51  <Brot6> FIRS Industry Replacement Set - Revision 2238:61c5d85febcc: Add: Templates for tile aware spritel... (Terkhen) @
14:41:52  <Brot6> FIRS Industry Replacement Set - Revision 2239:55297ff27910: Add: Sprite template with file parame... (Terkhen) @
14:41:52  <Brot6> FIRS Industry Replacement Set - Revision 2240:baf2ad28498c: Codechange: Use advanced spritelayout... (Terkhen) @
14:41:53  <Brot6> FIRS Industry Replacement Set - Revision 2241:2b8d393c0d25: Codechange: Use advanced spritelayout... (Terkhen) @
14:43:43  <planetmaker> :-)
14:44:18  <Terkhen> I'll prepare the rest of files before I start converting them
14:44:37  <Brot6> FIRS Industry Replacement Set - Revision 2242:70dc432d3a26: Doc: Add GPL header to all industry f... (Terkhen) @
14:47:05  <planetmaker> :-)
14:47:09  <planetmaker> sweet
14:52:16  <Brot6> OpenGFX - Bug #1676 (Assigned): Colour difference in paper truck sprites (foobar) @
14:52:43  <Terkhen> the aluminium plant passed from 2608 lines to 867 :P
14:52:53  <planetmaker> Ha!
14:53:09  <planetmaker> that really reduces clutter a bit :-)
14:54:01  <Terkhen> now to figure why the smoke stands frozen in the first frame :P
14:54:09  <Terkhen> of course I noticed it after commit
14:54:35  <planetmaker> no animation callback?
14:54:57  <Terkhen> I must have broke something while converting
14:55:23  <planetmaker> was just a random guess of mine...
14:55:24  <Brot6> FIRS Industry Replacement Set - Revision 2243:b9a438088ba0: Add: Definition of THIS_ID macro for ... (Terkhen) @
15:01:43  <planetmaker> so... let's return to the placement templates...
15:02:37  <Terkhen> heh, smoke did not work because I was testing with the scenario editor :P
15:02:48  <planetmaker> :-)
15:03:00  <planetmaker> Though I wonder why anims don't work there
15:03:49  *** ODM has joined #openttdcoop.devzone
15:04:01  <Terkhen> probably the animations are bound to the loop that takes care of production too :P
15:04:42  <planetmaker> maybe
15:05:42  <Brot6> FIRS Industry Replacement Set - Revision 2244:ca7577f992a5: Fix: Name a magic industry number (planetmaker) @
15:32:14  <Hirundo> They are bound to the gameloop, if that's what you mean :)
15:32:56  <Terkhen> yes :P
15:33:48  <Rubidium> maybe there are no daily, weekly, monthly, whateverly triggers in SE
15:34:14  <Brot6> FIRS Industry Replacement Set - Revision 2245:67f976c07faf: Codechange: Clean spritelayout code f... (Terkhen) @
15:34:55  <Rubidium> and (ofcourse) no AnimateTiles ;)
15:36:49  *** Lakie has joined #openttdcoop.devzone
15:40:19  <Brot6> FIRS Industry Replacement Set - Revision 2246:9da87f7c4ae4: Change: Rework availability template (planetmaker) @
15:43:53  <Brot6> FIRS Industry Replacement Set - Revision 2247:11f7a740c7e0: Codechange: Clarify spritelayout code... (Terkhen) @
15:55:09  <planetmaker> hm, clusters will  be dealt with later in a separate template
15:59:42  <Ammler> Terkhen: planetmaker, you guys do often ask the other, if you can push etc.?
15:59:52  <Ammler> maybe you wanna check extension lock
16:00:59  <Terkhen> I thought that if both of us tried to commit at the same time only one would be alowed
16:01:01  <Terkhen> allowed*
16:02:37  <planetmaker> not sure it's needed. It's mostly for our convenience to avoid rebasing
16:10:03  <Terkhen> bbl
16:12:12  <planetmaker> but it's an interesting idea, Ammler :-)
16:13:14  <Ammler> Terkhen: it can be an issue, if 2 work on same file
16:13:18  <Ammler> same as with svn
16:13:38  <Ammler> with lock, you can kind of reserve a file
16:21:42  <Brot6> OpenGFX - Revision 720:00eca3aff628: Feature: NMLify sprites/nfo/base/base-3092-road-vehicles.pnfo (foobar) @
16:41:36  *** frosch123 has joined #openttdcoop.devzone
16:48:41  <Brot6> NewGRF Meta Language - Revision 1585:0b2b759d99f9: Codechange/Fix: Change the way that the nvar =... (Hirundo) @
17:00:39  <Brot6> OpenGFX - Bug #1676 (Closed): Colour difference in paper truck sprites (foobar) @
17:00:39  <Brot6> OpenGFX - Revision 721:ee8790e26acd: Fix #1676: improve graphics of flatbed road vehicles (climat... (foobar) @
17:10:27  <Brot6> nml: update from r1580 to r1585 done -
17:18:23  <Brot6> OpenGFX - Feature #1221: Convert set to DOS palette? (foobar) @
17:19:43  <Brot6> firs: update from r2236 to r2247 done (37 warnings) -
17:21:33  <Brot6> opengfx: update from r719 to r721 done -
17:21:56  <Brot6> OpenGFX - Feature #1221: Convert set to DOS palette? (planetmaker) @
17:24:03  <Brot6> ogfx-landscape: update from r75 to r76 done (2 warnings) -
17:24:28  <Brot6> Following repos didn't need a nightlies update: ogfx-trains (r248), narvs (r37), bros (r52), ogfx-industries (r122), ailib-tile (r16), foobarstramtracks (r23), transrapidtrackset (r28), 2cctrainset (r750), cets (r126), ailib-list (r32), opensfx (r97), ttdviewer (r34), worldairlinersset (r672), heqs (r638), openmsx (r97), basecosts (r25), nutracks (r202), nml (r1585), 32bpp-extra (r40), manindu (r7), newgrf_makefile (r305),
17:24:28  <Brot6> ailib-direction (r17), ailib-common (r21), snowlinemod (r49), dutchtramset (r87), ai-admiralai (r75), swisstowns (r22), metrotrackset (r56), spanishtowns (r10), frenchtowns (r6), grfpack (r279), ogfx-rv (r107), fish (r684), ttrs (r36), ogfx-trees (r51), swedishrails (r205), grfcodec (r833), ai-aroai (r39), german-townnames (r34), smts (r19), chips (r143), belarusiantowns (r8), indonesiantowns (r41), ailib-string (r29), airportsplus
17:24:30  <Brot6> (r107), comic-houses (r71)
17:25:57  <Brot6> narvs: compile of r37 still failed (#2789) -
17:43:25  <Brot6> Central European Train Set - Feature #2924: Prussian steam engines - sprites (oberhuemer) @
17:43:43  <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: ogfx-trains (Diffsize: 281), ogfx-industries (Diffsize: 120), foobarstramtracks, cets (436 warnings) (Diffsize: 462), manindu (Diffsize: 2), newgrf_makefile, dutchtramset, swisstowns, spanishtowns (Diffsize: 2), frenchtowns, ogfx-rv (Diffsize: 4775), swedishrails, german-townnames (Diffsize: 1), belarusiantowns (Diffsize: 30), indonesiantowns (1
17:43:43  <Brot6> warnings) (Diffsize: 1), airportsplus (2 warnings) (Diffsize: 30186)
17:45:24  <Ammler> hmm, 2789 sucks, why does he not fix that?
17:46:18  <Brot6> North American Road Vehicle Set - Bug #2789: DevZone compile failed (Ammler) @
18:20:18  *** andythenorth has joined #openttdcoop.devzone
18:24:21  <Terkhen> andythenorth:
18:26:54  <Brot6> FIRS Industry Replacement Set - Revision 2248:ef384672f833: Codechange: Clarify spritelayout code... (Terkhen) @
18:27:48  <Terkhen> 5 done, 47 to go
18:41:11  <andythenorth> Terkhen: that count down is a game I have played often :P
18:41:25  <Terkhen> :)
18:41:33  <Terkhen> what do you think of the format?
18:45:24  <andythenorth> will look later - busy right now ;)
18:46:40  <Terkhen> ok
18:52:18  <Brot6> Nutracks - Revision 203:1d851d1bbd33: Removed lines at sprite edges (oberhuemer) @
18:52:24  *** Lakie` has joined #openttdcoop.devzone
18:52:42  <Brot6> nutracks: update from r202 to r203 done (1 warnings) -
18:53:02  <Brot6> Central European Train Set - Feature #2763: track classes / railtype support (michi_cc) @
18:58:13  *** Lakie has quit IRC
18:59:57  *** Lakie` is now known as Lakie
19:00:45  <Brot6> Nutracks - Bug #2715 (Closed): Lighten edges of ballast (oberhuemer) @
19:01:28  <Brot6> Nutracks - Bug #2948 (New): Slope offsets (oberhuemer) @
19:05:34  <Brot6> clientpatches: update from r22729 to r22730 done (6 warnings) -
19:09:59  <Brot6> openttd-vehiclevars: update from r22729 to r22730 done -
19:12:19  <Hirundo> Terkhen: wrt. firs biorefinery, can't all those anim spritelayouts be combined into one (with a parameter) ?
19:12:40  <andythenorth> if they are just the smoke animation, then yes
19:12:43  <Terkhen> maybe
19:12:48  <andythenorth> smoke is a prime case for advanced
19:12:52  <Terkhen> but I assumed they would require four parameters
19:12:54  <planetmaker> certainly :-)
19:13:02  <andythenorth> currently the maintainability of tiles with smoke *sucks*
19:13:16  <Terkhen> <--- one parameter for each one of those values
19:13:41  <Terkhen> or defining them all and hide/show depending on a temporal storage register
19:13:49  <Terkhen> is there any better way?
19:14:25  <Hirundo> sprite: first_sprite + animation_frame ?
19:14:25  <Terkhen> (for now I'm ignoring smoke btw, I plan to check how to deal with it after everything regarding spritelayouts is looking "nice")
19:14:52  <Terkhen> but they also have different xoffset/xextent/zoffset/zextent values
19:14:56  <Brot6> serverpatches: update from r22729 to r22730 done (10 warnings) -
19:15:47  <Hirundo> All 1/62/15/7 here (or is that a copy/paste error?)
19:17:01  <Brot6> 32bpp-ez-patches: compile of r22730 still failed (#2446) -
19:19:38  <Terkhen> actually I'm looking at the aluminium plant ones
19:20:31  <Terkhen> yes, the biorefinery could use a single one
19:21:18  <Terkhen> and in the aluminium plant, only zoffset changes
19:21:38  <Terkhen> and it is also increasing so yes, it is doable :P
19:23:03  <Terkhen> bbl
20:12:18  <Terkhen> <-- nice diff file :P
20:12:27  <Terkhen> lots of - and almost no +
20:14:11  <planetmaker> nice one. Yes, please go for it
20:14:57  <Terkhen> advanced sprite layouts are a huge change :P
20:15:05  <Brot6> FIRS Industry Replacement Set - Revision 2249:d3bb0ee28916: Codechange: Simplify Aluminium Plant ... (Terkhen) @
20:16:51  * planetmaker totally is in love with ASLs ;-)
20:21:04  <Terkhen> we have a lot of code to fix in ogfx-industries, yes :P
20:25:19  <planetmaker> meanwhile? Yes
20:25:26  <planetmaker> But... FIRS for now ;-)
20:25:31  <Terkhen> yes
20:25:34  <Brot6> FIRS Industry Replacement Set - Revision 2250:3f73ebbd3ea2: Codechange: Simplify Biorefinery anim... (Terkhen) @
20:25:37  <Terkhen> ogfx-industries is "done" for now :P
20:25:56  <planetmaker> we need to get andy a working newgrf again so he will provide graphics and graphics and graphics ;-)
20:26:00  <planetmaker> yup ;-)
20:26:04  <Terkhen> :P
20:26:08  <Terkhen> well, now it "works"
20:26:38  <planetmaker> Well, honestly. It does. And... motivation to change it will come as will new ideas, then it's time for that
20:26:43  <planetmaker> but that time is not now ;-)
20:26:49  <planetmaker> at least for me
20:27:06  <Terkhen> once that we finish templating production code and spritelayouts, what else is missing? now that spritelayouts have been converted into a mechanical process I can think on other stuff while I do it
20:27:39  <planetmaker> then there's not too much anymore.
20:27:42  <Hirundo> Converting parametrized spritelayouts to parametrized spritelayouts that don't need CPP? (once that's done in NML, of course) ?
20:27:43  <planetmaker> All will need checking
20:27:45  <Terkhen> and yes, right now I'm not on the state of mind to have great ideas either, sun and stress does that to my brain :P
20:28:05  <Terkhen> Hirundo: if you are planning to include that in NML I'll stop what I'm doing right now :P
20:28:09  <planetmaker> :-)
20:28:09  <Terkhen> and that would be awesome
20:28:32  <Hirundo> I am planning for some time, there's no ETA though
20:29:13  <Terkhen> conversion would be easy, I would just change the template to generate the parametrized layouts :P
20:29:19  <Terkhen> ok, I'll continue then :)
20:29:29  <Terkhen> but the change for animations is already a godsend
20:29:49  <Terkhen> 200 lines of nml code -> 2 lines
20:30:32  <andythenorth> that was one of the use cases :)
20:30:36  <andythenorth> that and fences
20:31:51  <Hirundo> I think I'll do "differing sprite counts in spritesets used by 1 group/layout" first, though
20:33:27  <Terkhen> that would be nice too, right now I'm forced to duplicate ground sprites in some cases :)
20:34:05  <Hirundo> That is, unless frosch123 is planning to trunk extended action1 soon (?), which'd make my hacking obsolete
20:34:35  <Hirundo> my hacking = padding spritesets with empty sprites
20:37:41  <frosch123> i would first want to discuss it with yexo
20:38:06  <frosch123> also the construction stage thingie is stupid :p
20:38:44  <Hirundo> what construction stage thingie?
20:39:11  <frosch123> industries and houses use 1 - 4 construction stage sprites
20:39:22  <frosch123> which are currently only stored once per action2
20:39:50  <frosch123> but if action2 can reference sets with different amount of sprites, it needs to be stored per set
20:40:03  <frosch123> which makes everything more complicated
20:40:30  <frosch123> though the advsprlayout code might have already made it complex enough, so it can also handle that :p
20:41:34  <Hirundo> I wonder, if the current handling of construction stages is correct
20:41:54  <Hirundo> First - how does it work if more than 4 sprites per spriteset are supplied?
20:41:55  <frosch123> it is "correct" as in "same as ttdp"
20:42:08  <frosch123> only the first 4 are used
20:42:39  <frosch123> ttdp stores the number of sprites for a spriteset somewhere in the action2
20:42:44  <Terkhen> hmm... there is something very strange in the brewery code
20:43:03  <Hirundo> Clamp(stage - 4 + tlgroup->num_building_stages, 0, tlgroup->num_building_stages - 1); <- I see no clamping to 4 here
20:44:19  <frosch123> hmm, yeah that looks weird
20:44:29  <frosch123> it uses the last 4 or so
20:44:46  <Hirundo> I'd guess so
20:44:47  <frosch123> even more complicated :p
20:44:53  <frosch123> i hope that is wrong
20:45:16  <Hirundo> Also the specs state "  if there are three sprites, the first will be used in the beginning of the construction (stage 0), the second will be used during the rest of the construction (stages 1 and 2) and the third will be used for the complete building (stage 3) "
20:46:01  <Hirundo> So the specs tell to use sprite 0, 1, 1, 2 while ottd does 0, 0, 1, 2
20:46:26  <Hirundo> A minor point really, but I noticed while studying possibilities to hack around action1 limitations :)
20:49:34  <Terkhen> ah, right, a macro :)
20:52:59  <andythenorth> construction stages suck :p
20:53:09  <andythenorth> I will have to draw them for FIRS.
20:53:12  <andythenorth> that will suck for me
20:53:20  <frosch123> ah, ttdp even has a look-up table for that
20:53:31  <frosch123> i was wondering about the bitmagic to produce 0,1,1,2 :)
20:53:54  <frosch123> (0,0,0,0), (0, 0, 0, 1), (0, 1, 1, 2), (0, 1, 2, 3)
20:54:03  <Hirundo> a lookup table? what a waste of valuable bits
20:54:09  <Hirundo> :o
20:54:35  <frosch123> well, i expected some fixed point arithmetics
20:55:02  <frosch123> something like stage * 3 / numsets or so
20:55:19  <frosch123> which would magically work for values 0 to 3
20:55:37  <Hirundo> that'd be standard for TTDP indeed
21:00:28  <planetmaker> <-- I think I used something like string()
21:01:26  <planetmaker> the modification is a simple addition to
21:02:28  <planetmaker> <-- applies to FIRS head and then triggers it
21:04:07  <andythenorth> bed time
21:04:09  <andythenorth> good night
21:04:14  <andythenorth> it's been a riot :p
21:04:15  *** andythenorth has left #openttdcoop.devzone
21:05:00  <Hirundo> planetmaker: Apparently, no-one tried entering "string()" before
21:05:21  <planetmaker> I'm not entirely sure whether it does that... it's just a gut feeling
21:05:30  <planetmaker> I didn't yet test and cross-check all that code well
21:06:47  <Hirundo> I did ... waiting for the FIRS makefile to start bug-hunting takes a long time on cygwin :S so I avoided that step
21:06:58  <planetmaker> but yes, it exists in the resulting NML: return string()
21:07:25  <planetmaker> I need a default string it seems ;-)
21:08:38  <planetmaker> also template fail :S
21:12:16  <Brot6> Central European Train Set - Feature #2763: track classes / railtype support (Eddi) @
21:14:02  <Brot6> Central European Train Set - Feature #2763: track classes / railtype support (Eddi) @
21:15:01  <Brot6> Central European Train Set - Feature #2763: track classes / railtype support (Eddi) @
21:15:33  <Brot6> Central European Train Set - Feature #2763: track classes / railtype support (Eddi) @
21:31:51  *** Lakie has quit IRC
21:32:34  <Brot6> Central European Train Set - Feature #2763: track classes / railtype support (Eddi) @
21:33:09  *** frosch123 has quit IRC
22:25:46  *** ODM has quit IRC
22:25:53  <Hirundo> planetmaker: Bug is fixed (locally)
22:28:14  <Brot6> NewGRF Meta Language - Revision 1586:c88f0abe4b2a: Fix: Validate argument count and type of strin... (Hirundo) @

Powered by YARRSTE version: svn-trunk