Times are UTC Toggle Colours
08:03:17 <Brot6> FIRS Industry Replacement Set - Revision 2237:7f1d10be121a: Cleanup: Remove unused and unneeded t... (planetmaker) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/7f1d10be121a 10:17:14 <Terkhen> planetmaker: http://paste.openttdcoop.org/show/430/ 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> http://paste.openttdcoop.org/show/431/ <--- 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) @ http://dev.openttdcoop.org/issues/2945 10:45:02 <Brot6> HEQS "Heavy Equipment" Set - Bug #2946 (New): The Forklift changes to the "1950" model in the y... (andythenorth) @ http://dev.openttdcoop.org/issues/2946 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> http://paste.openttdcoop.org/show/432/ <--- 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> http://paste.openttdcoop.org/show/433/ <--- 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> http://paste.openttdcoop.org/show/434/ 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> http://paste.openttdcoop.org/show/435/ 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> http://devs.openttd.org/~terkhen/patches/index.php?source=010_food_market_example.diff <--- 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> http://paste.openttdcoop.org/show/436/ 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> http://paste.openttdcoop.org/show/437/ 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> http://paste.openttdcoop.org/show/438/ <-- 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> https://munin.openttdcoop.org/ 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 (https://www.icinga.org/) 13:52:41 <Webster> Title: Home - Open Source Monitoring (at www.icinga.org) 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> https://munin.openttdcoop.org/openttdcoop.org/haydn.openttdcoop.org/index.html 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) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/61c5d85febcc 14:41:52 <Brot6> FIRS Industry Replacement Set - Revision 2239:55297ff27910: Add: Sprite template with file parame... (Terkhen) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/55297ff27910 14:41:52 <Brot6> FIRS Industry Replacement Set - Revision 2240:baf2ad28498c: Codechange: Use advanced spritelayout... (Terkhen) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/baf2ad28498c 14:41:53 <Brot6> FIRS Industry Replacement Set - Revision 2241:2b8d393c0d25: Codechange: Use advanced spritelayout... (Terkhen) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/2b8d393c0d25 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) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/70dc432d3a26 14:47:05 <planetmaker> :-) 14:47:09 <planetmaker> sweet 14:52:16 <Brot6> OpenGFX - Bug #1676 (Assigned): Colour difference in paper truck sprites (foobar) @ http://dev.openttdcoop.org/issues/1676#change-7366 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) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/b9a438088ba0 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) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/ca7577f992a5 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) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/67f976c07faf 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) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/9da87f7c4ae4 15:43:53 <Brot6> FIRS Industry Replacement Set - Revision 2247:11f7a740c7e0: Codechange: Clarify spritelayout code... (Terkhen) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/11f7a740c7e0 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) @ http://dev.openttdcoop.org/projects/opengfx/repository/revisions/00eca3aff628 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) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/0b2b759d99f9 17:00:39 <Brot6> OpenGFX - Bug #1676 (Closed): Colour difference in paper truck sprites (foobar) @ http://dev.openttdcoop.org/issues/1676#change-7370 17:00:39 <Brot6> OpenGFX - Revision 721:ee8790e26acd: Fix #1676: improve graphics of flatbed road vehicles (climat... (foobar) @ http://dev.openttdcoop.org/projects/opengfx/repository/revisions/ee8790e26acd 17:10:27 <Brot6> nml: update from r1580 to r1585 done - http://bundles.openttdcoop.org/nml/nightlies/r1585 17:18:23 <Brot6> OpenGFX - Feature #1221: Convert set to DOS palette? (foobar) @ http://dev.openttdcoop.org/issues/1221#change-7371 17:19:43 <Brot6> firs: update from r2236 to r2247 done (37 warnings) - http://bundles.openttdcoop.org/firs/nightlies/r2247 17:21:33 <Brot6> opengfx: update from r719 to r721 done - http://bundles.openttdcoop.org/opengfx/nightlies/r721 17:21:56 <Brot6> OpenGFX - Feature #1221: Convert set to DOS palette? (planetmaker) @ http://dev.openttdcoop.org/issues/1221#change-7372 17:24:03 <Brot6> ogfx-landscape: update from r75 to r76 done (2 warnings) - http://bundles.openttdcoop.org/ogfx-landscape/nightlies/r76 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) - http://bundles.openttdcoop.org/narvs/nightlies/ERROR/r37 17:43:25 <Brot6> Central European Train Set - Feature #2924: Prussian steam engines - sprites (oberhuemer) @ http://dev.openttdcoop.org/issues/2924#change-7377 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) @ http://dev.openttdcoop.org/issues/2789#change-7378 18:20:18 *** andythenorth has joined #openttdcoop.devzone 18:24:21 <Terkhen> andythenorth: http://dev.openttdcoop.org/projects/firs/repository/entry/sprites/nml/industries/aluminium_plant.pnml 18:26:54 <Brot6> FIRS Industry Replacement Set - Revision 2248:ef384672f833: Codechange: Clarify spritelayout code... (Terkhen) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/ef384672f833 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) @ http://dev.openttdcoop.org/projects/nutracks/repository/revisions/1d851d1bbd33 18:52:24 *** Lakie` has joined #openttdcoop.devzone 18:52:42 <Brot6> nutracks: update from r202 to r203 done (1 warnings) - http://bundles.openttdcoop.org/nutracks/push/r203 18:53:02 <Brot6> Central European Train Set - Feature #2763: track classes / railtype support (michi_cc) @ http://dev.openttdcoop.org/issues/2763#change-7379 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) @ http://dev.openttdcoop.org/issues/2715#change-7380 19:01:28 <Brot6> Nutracks - Bug #2948 (New): Slope offsets (oberhuemer) @ http://dev.openttdcoop.org/issues/2948 19:05:34 <Brot6> clientpatches: update from r22729 to r22730 done (6 warnings) - http://bundles.openttdcoop.org/clientpatches/testing/r22730 19:09:59 <Brot6> openttd-vehiclevars: update from r22729 to r22730 done - http://bundles.openttdcoop.org/openttd-vehiclevars/testing/r22730 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> http://paste.openttdcoop.org/show/440/ <--- 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) - http://bundles.openttdcoop.org/serverpatches/testing/r22730 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) - http://bundles.openttdcoop.org/32bpp-ez-patches/testing/ERROR/r22730 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> http://devs.openttd.org/~terkhen/patches/aluminium_animation.diff <-- 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) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/d3bb0ee28916 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) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/3f73ebbd3ea2 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> http://paste.openttdcoop.org/show/441/ <-- I think I used something like string() 21:01:26 <planetmaker> the modification is a simple addition to global_constants.py 21:02:28 <planetmaker> http://devs.openttd.org/~planetmaker/patches/nml_internal_error.diff <-- 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) @ http://dev.openttdcoop.org/issues/2763#change-7381 21:14:02 <Brot6> Central European Train Set - Feature #2763: track classes / railtype support (Eddi) @ http://dev.openttdcoop.org/issues/2763#change-7381 21:15:01 <Brot6> Central European Train Set - Feature #2763: track classes / railtype support (Eddi) @ http://dev.openttdcoop.org/issues/2763#change-7381 21:15:33 <Brot6> Central European Train Set - Feature #2763: track classes / railtype support (Eddi) @ http://dev.openttdcoop.org/issues/2763#change-7381 21:31:51 *** Lakie has quit IRC 21:32:34 <Brot6> Central European Train Set - Feature #2763: track classes / railtype support (Eddi) @ http://dev.openttdcoop.org/issues/2763#change-7381 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) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/c88f0abe4b2a