Times are UTC Toggle Colours
00:29:41 *** Lakie has quit IRC 01:57:34 <Brot6> Central European Train Set - Feature #3045 (New): Wagons - sprites (Elukka) @ http://dev.openttdcoop.org/issues/3045 06:45:09 *** ODM has joined #openttdcoop.devzone 07:18:12 *** michi_cc has joined #openttdcoop.devzone 08:05:29 <Terkhen> planetmaker: opengfx+ landscape has a list of things that are missing gridless sprites? 08:05:36 <Terkhen> I just noticed something new: rivers :P 08:32:28 <Brot6> FIRS Industry Replacement Set - Bug #3046 (New): Town industry overcrowding (Terkhen) @ http://dev.openttdcoop.org/issues/3046 08:35:56 <planetmaker> moin 08:36:04 <planetmaker> Terkhen, yes, I noticed rivers, too :-) 08:36:17 <planetmaker> Luckily my new river border sprites are in my (big) landscape file 08:36:25 <planetmaker> Thus I have grids in a separate layer 08:36:34 <planetmaker> And that will come when I submit them also to OpenGFX 08:36:58 <planetmaker> But I so far only have the flat river borders done 08:37:01 <planetmaker> 4 slopes to go... 08:38:02 <planetmaker> but it has no list of "needs gridless sprites". Please make a ticket, if you see other than rivers :-) 08:39:22 <planetmaker> But rivers might still take a bit time. It's lengthy to draw :-) 08:39:27 <planetmaker> You know how that goes... 08:39:46 <planetmaker> and fixing OpenGFX has a bit priority. +Landscape is then a spin-off ;-) 08:39:54 <planetmaker> which comes at 10% extra cost ;-) 08:42:25 <planetmaker> I'm considering to submit the level river sprites first, though. But I'm missing snow sprites there so far :-) 08:42:32 <planetmaker> There I need to draw something extra... 08:43:00 <planetmaker> All other terrains use the normal river borders as overlay on the terrain (in the file itself, not as sprites) 08:43:43 <planetmaker> and no, I didn't yet submit that landscape file... it's 1 MByte already... and changing it for each sprite would bloat the repo needlessly ;-) 08:44:51 <Terkhen> I see :) 08:45:05 <Terkhen> to my knowledge, only rivers, roads and rails 08:45:13 <planetmaker> roads and rails? 08:45:16 <planetmaker> They should be fine 08:45:30 <planetmaker> or so I thought 08:45:43 <planetmaker> didn't I finish that? 08:45:52 <planetmaker> or rather: forgot some? 08:54:28 <Terkhen> with 0.2.2, I can see the grids on road tiles 08:54:47 <planetmaker> - Feature: No-grid versions of roads 08:54:47 <planetmaker> <---hmm :S 08:54:50 <Terkhen> :P 08:54:56 <Terkhen> same for rails 08:58:13 <planetmaker> :-( 08:59:34 <planetmaker> really? I don't see them 08:59:38 <Terkhen> I'm playing on alpine 08:59:40 <Terkhen> maybe that's related 09:00:21 <planetmaker> hm... 09:00:24 <planetmaker> I need to check that 09:00:58 <Terkhen> indeed; I disabled it and I see no grids on roads 09:01:00 <planetmaker> seems to be 09:01:09 <planetmaker> thanks for noticing :-) 09:01:10 <Terkhen> neither on rails 09:01:17 <Terkhen> only rivers on that case :) 09:01:22 <Terkhen> should I make a bug report 09:01:24 <Terkhen> ? 09:01:27 <planetmaker> please :-) 09:01:50 <planetmaker> should be easy to fix. It's only code then 09:02:00 <planetmaker> actually skip the bug report 09:02:39 <Terkhen> too late :P 09:02:44 <Brot6> OpenGFX+ Landscape - Bug #3047 (New): Grid problem with the Alpine option (Terkhen) @ http://dev.openttdcoop.org/issues/3047 09:03:43 <Terkhen> is there any reason for allowing Alpine on subtropical? IMO it would be better to silently ignore the option in that case 09:03:46 <Brot6> OpenGFX+ Landscape - Feature Request #3048 (New): Gridless sprite missing for rivers (Terkhen) @ http://dev.openttdcoop.org/issues/3048 09:05:05 <planetmaker> The reason I didn't disallow it is that it has a certain kind of charm, like green coasts and snowy interiors. 09:05:09 <planetmaker> But I agree that it's strange 09:05:45 <planetmaker> It seems I'm missing some gridless sprites anyway when I look at the sprite templates 09:05:50 <planetmaker> like for level crossings 09:06:27 <planetmaker> and monorail... 09:07:20 <Brot6> OpenGFX+ Landscape - Bug #3047: Grid problem with the Alpine option (planetmaker) @ http://dev.openttdcoop.org/issues/3047#change-7765 09:08:19 <Brot6> OpenGFX+ Landscape - Feature Request #3049 (New): Ignore Alpine when climate is subtropical (Terkhen) @ http://dev.openttdcoop.org/issues/3049 09:09:59 <planetmaker> maybe a boolean parameter like "allow crazy stuff" ;-) 09:10:04 <Terkhen> :P 09:10:19 <Brot6> OpenGFX+ Landscape - Revision 86:23edfc18d2a6: Change #3047: Add the existing gridless sprites fo... (planetmaker) @ http://dev.openttdcoop.org/projects/ogfx-landscape/repository/revisions/23edfc18d2a6 09:10:49 <planetmaker> you're not the first to mention snow in tropical. I indeed left it in for the reason "crazy, but interesting" 09:11:27 <planetmaker> but your argument of "is unexpected" is valid, too 09:13:04 <Brot6> OpenGFX+ Landscape - Bug #2997 (Rejected): DevZone compile failed (planetmaker) @ http://dev.openttdcoop.org/issues/2997#change-7766 09:14:51 <planetmaker> I still want savannah tiles instead of desert :-) 09:15:27 <planetmaker> and I wonder whether I should (I have permission) use somewhere the arctic shores from NewWater :-) 09:18:27 <Terkhen> artic shores? OpenTTD allows to decide between snow / normal tiles on that case? 09:20:09 <planetmaker> Not snowy. But that NewGRF has a different shore sprite than OpenGFX has now 09:20:13 <planetmaker> And it looks quite good, too 09:21:24 <V453000> morning ... is it legal to take some things from the TTD base set? Talking about steel on wagons - for example UKRS is using it too but I think mirrored... 09:21:49 <planetmaker> it's not 09:22:07 <planetmaker> it's intelectual property theft 09:22:25 <planetmaker> unless you get a written permission from Chris Sawyer of Simon Foster 09:22:36 <planetmaker> *or 09:22:43 <V453000> oh, so pikka likely has that? 09:23:45 <planetmaker> certainly not 09:24:00 <V453000> oh :o 09:25:24 <Terkhen> opengfx exists for a reason :P 09:26:00 <planetmaker> :-) 09:26:06 <V453000> so UKRS is basically legally wrong? 09:26:23 <planetmaker> if he used TTD sprites: yes 09:26:29 <Terkhen> I'm no lawyer so I can only say that I wouldn't have done that for my sets :P 09:26:30 <planetmaker> Not sure he did 09:26:45 <planetmaker> I'd subscribe to Terkhen just said :-) 09:26:49 <planetmaker> It's at least grey area 09:26:51 <Terkhen> if you only want cargos, you might want to borrow opengfx+ trains ones; steel on wagons looks similar enough to not break style much 09:27:19 <V453000> hmm :) 09:28:12 <V453000> hmm the wagons are actually almost equal in ukrs and ttd 09:28:22 <planetmaker> see. That's where the problem starts :-) 09:28:56 <V453000> I know 09:29:00 *** hanf has joined #openttdcoop.devzone 09:30:04 <planetmaker> maybe you try (as others before) to get permission to mod TTD or have them release TTD in the public domain ;-) 09:30:09 <V453000> guess I will have to invent my own steel :d 09:30:11 <planetmaker> I'd not count on you being successful, though 09:30:52 <planetmaker> as they don't even seem to know who actually would be allowed to say so ;-) 09:31:02 <V453000> :D 09:32:23 <V453000> ha, DB set has something "just similar" 09:32:30 <planetmaker> reusing OpenGFX' steel has the advantage that there's no break in style for 2/3 of the people 09:33:02 <V453000> you know very well what I think about that 09:33:12 <planetmaker> yes. 09:33:34 <planetmaker> for the wrong reasons 09:34:22 <V453000> I cant make myself like how it looks, that is impossible, and quite honestly the more I draw the more solid my opinion is, but on the other hand if I make some nice steel I might hand it over to you :p 09:34:51 <planetmaker> this discussion we just had should have shown you that the proper way would be to improve OpenGFX ;-) 09:35:30 <V453000> <V453000> ... I might hand it over to you :p 09:35:33 <planetmaker> but you unfortunately approach it with disdain and an attitude of "ugly and won't fix" 09:35:52 <planetmaker> you couldn't even stop me, if I liked, if you use GPL ;-) 09:36:13 <planetmaker> and we couldn't host the set, if it wasn't a community - friendly license :-P 09:36:34 <planetmaker> lalala :-P 09:36:53 <V453000> so you are basically telling me that I either share the stuff or fuck off 09:37:08 <planetmaker> No. 09:37:31 <planetmaker> I'm telling you that users of the Devzone are required to share stuff 09:37:31 <V453000> I just told you that I might give you sprites for steel if I make some nice ... what else do you want 09:37:52 <planetmaker> which all proper licenses allow 09:38:09 <planetmaker> whether I use your sprites or not... I don't know 09:38:41 <planetmaker> question is, why should I? ;-) 09:38:53 <planetmaker> I might, if it makes conceptually sense 09:39:56 <planetmaker> maybe you should read my blog article on licenses (again) ;-) 09:40:52 <V453000> I dont know I just feel like using any sprites elsewhere just makes it lood dumb and unified, while I want my set to remain unique, so be it any other train set or even opengfx which would share my sprites, I would not feel very good about that 09:41:00 <V453000> I know I read it at least twice 09:41:27 <planetmaker> well. Then allow no-one to re-use your sprites. But then develop your set elsewhere 09:41:59 <V453000> I thought about something like that, yes 09:42:01 <planetmaker> Giving the permission to re-use sprites also doesn't mean they will be used by anyone 09:42:06 <V453000> I know 09:42:53 <V453000> ok, that basically answers my thoughts on what sort of license to pick :) 09:43:05 <planetmaker> and which? 09:43:19 <V453000> Then allow no-one to re-use your sprites. But then develop your set elsewher <- sounds friendly enough, doesnt it? 09:43:48 <planetmaker> That's the terms of conditions for the DevZone 09:44:05 <planetmaker> We offer it for free to the community, if people give something back to the community 09:44:19 <planetmaker> And that means that one can build on it, continue work, branch work 09:44:36 <planetmaker> Like it worked nicely for TTRS 09:44:50 <V453000> yes, that is one of the examples I imagined 09:44:51 <planetmaker> Without a permissive license it wouldn't be on bananas, it wouldn't have parameter view 09:45:07 <V453000> but nobody can re-use ttrs sprites? 09:45:11 <planetmaker> everyone can 09:45:18 <planetmaker> that's what I'm saying 09:45:31 <planetmaker> they allow everyone to make derivatives. To use it in projects as see people fit 09:45:38 <planetmaker> As long as one gives credits 09:45:47 <^Spike^> in the end that is not an unreasonable request from the devzone... there are lots of communities that work on that basis.... software company atlassian is a perfect example of that.. they have expensive SW packages for development etc but if you are opensource you can use them for free... 09:45:49 <planetmaker> To extend the set as people see fit 09:46:09 <V453000> ^Spike^: I understand that :) 09:46:12 <^Spike^> with the though behind it if you share... you can use this for free 09:46:23 <^Spike^> and atlassian has expensive packages :D 09:46:27 <^Spike^> i know that :) 09:46:31 <^Spike^> shame they run on java though :) 09:46:32 <planetmaker> :-) 09:47:02 <V453000> OH ... dog damn english 09:47:08 <V453000> of course I just misunderstood ... 09:47:21 <planetmaker> ? 09:47:42 <V453000> hen allow no-one to re-use your sprites. But then develop your set elsewhere ... I understood as "I let people edit develop the set but not re-use sprites. 09:48:06 <V453000> which would have explained all my questions from there 09:49:40 <planetmaker> aye 09:53:39 <V453000> guess I better start packing then 09:55:04 <planetmaker> so you don't want to be part of an open-source community? 09:55:52 <planetmaker> and give something back to the community? 09:57:33 <planetmaker> you know. The whole game only works _because_ it is open source 09:57:35 <planetmaker> Think of it 09:57:41 <planetmaker> That's why OpenTTD is what it is 09:57:48 <planetmaker> Anyone can do anything with it and it's source 09:57:55 <planetmaker> Without asking anyone for any permission 09:58:02 <planetmaker> As long as they allow the same with their work 09:58:26 <planetmaker> We're here and what we are only because of this libertarian way to deal with things 09:59:32 <V453000> I know 09:59:38 <dihedral> why do i have a highlight on java? :-P 09:59:40 <dihedral> grrr 10:00:07 <planetmaker> And why do you think it's better if you handle it in a way commercial companies like MS or oracle handle it? 10:00:07 <^Spike^> lol 10:00:17 <V453000> I would like to keep the stuff available within the project, so anyone could continue, is something like that possible? 10:00:44 <V453000> I just do not want my sprites to be duplicit with whatever else 10:00:44 <V453000> that is all 10:00:57 <^Spike^> you don't want your spirtes reused..? 10:01:11 <V453000> exactly 10:02:10 <planetmaker> how likely do you think it is that your sprites will be used by anyone else? 10:02:23 <planetmaker> if they're excellent: maybe some 10:02:27 <planetmaker> if not... possibly not 10:02:32 <V453000> I dont know 10:02:37 <planetmaker> come down from your vanity trip, I'd say :-) 10:02:48 <V453000> I do not even say the sprites are good 10:02:49 <^Spike^> well the question would also be with reusing do you mean others using the in-game? 10:02:58 <^Spike^> them* 10:03:23 <planetmaker> Well, but I see your point. Do what you like. Where you like. I'm tired to argue 10:03:39 <^Spike^> i guess intellectual property is a hard subject anyway 10:03:53 <planetmaker> Here we allow open-source projects without no-derivative clauses only 10:04:09 <V453000> I am not trying to argue, just see how things work and combine it with my interests 10:04:34 <Rubidium> V453000: allowing anyone to continue implies allowing anyone to fork, and thus use your sprites in another project (if it at least were a fork of your project in the past) 10:05:42 <V453000> yes, that is what I also wondered about 10:07:22 <Rubidium> though I wonder about the reasoning for having cargo look different between trains and road vehicles, or are you going to make your own style for all graphics? 10:07:53 <V453000> I guess I have to 10:08:21 <planetmaker> and incompatible to every existing set? 10:08:43 <Yexo> V453000: how many sets have you seen that used a significant portion of FIRS sprites? or from 2ccset? or from TTRS? or from .... ? 10:09:13 <V453000> I know, you are right Yexo 10:10:20 <V453000> well, pm, which two sets have really "compatible" cargoes :) 10:10:46 <V453000> but I think you have convinced me guys 10:12:36 <Terkhen> there is an ongoing effort right now to make cargos look the same in as many sets as possible 10:14:08 <V453000> hm, 2cc set uses the TTD steel as well ... 10:15:03 <V453000> Terkhen: I understand that and I myself draw it to make it look at least similar or reminding about how the cargo looks in other cases, steel is a bit hard there though 10:20:00 <V453000> mirrored ... 10:20:18 <V453000> so I suppose if I use that it is not _that_ bad 10:22:01 <planetmaker> re-using 2cc set sprites requires you to use GPL v2+ as license, though ;-) 10:22:07 <planetmaker> even when you modify them 10:22:45 <V453000> yes 10:24:52 <V453000> I was rather wondering about the ttd steel there 10:27:50 <Terkhen> I can't check right now, but if that's true then it is bad :P 10:28:35 <V453000> possibly not that bad if nobody noticed yet 10:29:09 <planetmaker> what makes you assume no-one noticed it? 10:29:19 <planetmaker> no-one cared, I bet :-P 10:29:21 <V453000> that it is still there :) 10:29:22 <Terkhen> why is it licensed as gpl? 10:29:26 <V453000> isn't that the same :P 10:29:35 <Terkhen> they can't relicense those 10:40:58 *** ODM has quit IRC 10:42:00 *** ODM has joined #openttdcoop.devzone 12:03:53 <Ammler> V453000: you do not really need to fear, people will use your stuff, just because you make a sharefriendly license 12:04:06 <Ammler> you still need to make nice stuff 12:04:25 <Ammler> same as you don't like opengfx, but it is GPL 12:05:20 <Ammler> actually, it is a high compliment, if others like to use your stuff, just ask andy :-) 12:06:12 <planetmaker> good thing is also George considers to move to an open-source license. He just may not due to graphics (still?) used which do not allow that 12:06:43 <Ammler> the issue there is that most artists have "do-not-care" license 12:06:43 <planetmaker> s/due/do/ 12:06:56 <planetmaker> which is the same as so-not-allow :-) 12:07:02 <Ammler> which is same as "do-not-have" license :-) 12:07:16 <planetmaker> btw, Ammler, NewWater sprites now may be used :-) 12:07:28 <Ammler> planetmaker: long ago already 12:07:38 <planetmaker> did it have a license which allows that? 12:07:40 <Ammler> you didn't ask him, I hope :-) 12:07:41 <planetmaker> I didn't see any 12:07:48 <Yexo> from what I've heard george has always been very liberal with giving permission to reuse his sprites 12:08:01 <planetmaker> yes, he has been and he is. Very much so 12:08:07 <Ammler> Yexo: not that easy for stuff he doesn't own 12:08:08 <planetmaker> he's very forthcoming 12:08:30 <planetmaker> but the stuff he didn't draw, that's the issue and reason for the ND part. Or so he told me somewhat recently 12:08:41 <Ammler> yes 12:08:59 <Ammler> planetmaker: newwater was part of opengfx since start, iirc 12:09:09 <planetmaker> Ammler: no, not all 12:09:18 <planetmaker> the temperate shore was used 12:09:22 <Ammler> I don't think, they asked for parts back then 12:09:26 <planetmaker> the rest not 12:09:28 <Ammler> they just didn't use everything 12:09:59 <planetmaker> I do not know how it worked and how permission was given. There's no note that all sprites were contributed 12:10:10 <Ammler> hehe, would need to read the dev thread from start to be sure :-P 12:10:12 <planetmaker> thus OpenGFX can only use those which it has. 12:10:25 <planetmaker> Though Lepkka allowed me to use his sprites for whatever I want :-) 12:10:32 <planetmaker> all of the NewWater sprites 12:10:49 <Ammler> then you should add the png to the source 12:11:09 <Ammler> hmm, anyway, so you plan to replace the arctic shores? 12:11:14 <planetmaker> well... 12:11:29 <planetmaker> I'm considering that. Or maybe I make it an option in ogfx+landscape. Dunno 12:11:35 <planetmaker> the shore is very nice indeed 12:12:33 <Ammler> I already told andy as he made the rivers, that sand shores aren't that nice 12:13:06 <Ammler> I meant sand shores everywhere 12:13:45 <planetmaker> well :-) 12:13:50 <Ammler> just bought a new laptop, dell xps 15 12:13:50 <planetmaker> the new rivers have muddy shores 12:13:59 <planetmaker> woo :-) 12:14:04 <Ammler> maybe then I can play again openttd :-P 12:14:10 <planetmaker> (my new ones) 12:16:07 <Ammler> planetmaker: are those already part of opengfx? 12:17:04 <planetmaker> not yet 12:17:19 <planetmaker> http://imagebin.org/171571 <-- like that 12:17:20 <Webster> Title: Imagebin - A place to slap up your images. (at imagebin.org) 12:17:29 <planetmaker> I haven't finished drawing yet 12:17:50 <planetmaker> only the new river water is part of OpenGFX so far 12:18:04 <Ammler> indeed VERY nic 12:18:05 <Ammler> e 12:18:25 <Terkhen> looks quite nice, yes :) 12:19:04 <Yexo> planetmaker: do you know which town variables FIRS uses (if any)? 12:19:08 <planetmaker> it will also become partially snow-aware ;-) 12:19:12 <Brot6> NewGRF Meta Language - Feature #2977: town variables (yexo) @ http://dev.openttdcoop.org/issues/2977#change-7768 12:19:18 <planetmaker> Yexo: iirc population 12:19:34 <planetmaker> not sure about others 12:19:55 <Yexo> ok, thanks 12:21:05 <planetmaker> some industries check distance from town centre, too... so that might be a town variable, too 12:21:11 <planetmaker> fishing harbour iirc does that. 12:21:22 <planetmaker> and population for market / hotel / hardware store or similar 12:22:10 <Yexo> there is an industry var for distance to closest town 12:22:30 <planetmaker> that's used in that case then 12:22:40 <Yexo> any comments on my list in #2977? 12:22:40 <Brot6> Yexo: #2977 is http://dev.openttdcoop.org/issues/show/2977 "NewGRF Meta Language - Feature #2977: town variables - #openttdcoop Development Zone" 12:32:32 <Rubidium> Ammler: I hope it doesn't break ;) 12:36:39 <planetmaker> Yexo: basically all "doubt" variables would allow for a nice economic changes 12:36:56 <planetmaker> or interesting effects 12:37:08 <planetmaker> like company statue along with station rating callback makes sense 12:37:23 <Yexo> it doesn't 12:37:27 <planetmaker> no? 12:37:38 <Yexo> the station rating callback doesn't replace the complete calculation, only part of it 12:37:51 <Yexo> things like statue bonus are added regardless of the callback 12:38:08 <Yexo> although if the check was available you could essentially reverse adding the bonus, thus disabling it 12:38:13 <Yexo> hmm, that might be interesting ;) 12:38:17 <planetmaker> :-) 12:38:34 <Yexo> only cargoes don't have a related object 12:38:51 <planetmaker> and passenger and mail % transported from a town make IMHO for interesting effects, too 12:38:59 <planetmaker> like hotels only open when there's demand or so 12:39:18 <planetmaker> same with the other vars 12:39:26 <planetmaker> for maybe the cargo production callback 12:39:49 <planetmaker> (not that it wouldn't break the industry chain view, but that's done anyway, unrelated to those vars) 12:39:58 <Yexo> ok :) 12:40:13 <planetmaker> and is_city allows for other layouts in the big boomtowns 12:40:29 <planetmaker> Not that I have immediate plans for any. But ... :-) 12:40:34 <Yexo> yes, only "problem" there was that I think it works differently in ttdpatch, but then ttdpatch isn't supported anyway 12:40:49 <planetmaker> exactly. Not even nightlies anymore ;-) 12:41:13 <Yexo> I meant: NML doesn't support ttdpatch with a lot of it's output 12:41:31 <planetmaker> yes, that, too 12:41:54 <planetmaker> it's very hard to guard non-ttdp code against execution 12:42:01 <planetmaker> I woudln't really want to try 12:42:25 <Yexo> that, and I don't have a good way to test what is and what isn't supported 12:43:04 <planetmaker> our leaf frog might know, but... 12:44:02 <planetmaker> more trouble than it seems worth 13:00:27 <Terkhen> CA..D3 might not be the "good" way to obtain that info if in the future some form of town control is introduced, but then they could just be deprecated in nml 13:00:49 <Terkhen> I was thinking that is_city wasn't very useful but I agree on what you have said 13:01:26 <Terkhen> you can't modify statue behaviour with NewObjects, right? 13:01:44 <Yexo> no 13:02:48 <Terkhen> then you can't alter the statue to store something in a register when it is built, but even then I'm not sure if statues would be useful 13:03:06 <Terkhen> I dislike the statue mechanic so I don't think that it should be used further for other things :P 13:04:36 <Yexo> ok, I'll add "is_city" and "percent passengers/mail", but not the statue var and not the variables about food/water 13:04:38 <planetmaker> one cannot change default objects at all actually 13:04:49 <planetmaker> hm... why not food / water? 13:05:35 <Yexo> because afaik it's only about the current month, so fairly useless at the start of each month, and with the introduction of "town control" grfs it will become obsolete 13:05:48 <Yexo> if a project wants to use it we can still add them 13:06:16 <planetmaker> hm... ok 13:07:45 * Hirundo agrees with the above discussion 13:13:39 <Terkhen> ok :) 13:14:32 <Ammler> Rubidium: you mean the tar thing? 13:14:58 <Rubidium> Ammler: I meant your new Dell 13:15:05 <Ammler> ah 13:15:09 <Ammler> :-) 13:15:24 <Ammler> I hope so either, my current dell just broke today 13:15:27 <Yexo> suggestions on naming for var 40? I wanted "is_city", but that might be confusing since it has 3 possible values (0 = not a city, 1 = city, 2 = no cities on the map at all) 13:15:48 <Ammler> this time I bought again 3 years support 13:15:57 <Yexo> could also split it in two: "is_city" (just bit 0) and "map_has_cities" (inverse of bit 1) 13:16:10 <Yexo> or "map_has_no_cities" for second one 13:19:20 <Terkhen> I think it's better splitted, yes 13:28:41 <Yexo> http://devs.openttd.org/~yexo/town_vars.diff Any comments on the naming? 13:33:33 <Terkhen> looks fine to me 13:34:27 *** Lakie has joined #openttdcoop.devzone 13:35:25 <planetmaker> Yexo: city_status? 13:35:48 <planetmaker> ah, nvm. you solution is better 13:37:32 <planetmaker> hm... pct as percent is strange to me. 13:37:41 <planetmaker> Yexo: could percent be written out in the var names? 13:38:10 <Yexo> sure 13:38:43 <planetmaker> maybe also passenger 13:39:13 <planetmaker> we're not charged for the extra letters ;-) 13:39:38 <Yexo> done :) 13:39:41 <planetmaker> thanks :-) 13:47:35 <Hirundo> Yexo: map_has_no_cities is a negative, that gets confusing easily 13:48:10 <Hirundo> I'd do map_has_cities, even if it means slightly more work to code 13:49:08 <Hirundo> hmm.... is such info not globally available via some flag/bit? 13:50:15 <Yexo> doesn't seem to be 13:53:02 <Hirundo> I'm not quite happy as map_has_cities might be 1 even if there are no cities (by chance) 13:53:20 <Hirundo> perhaps cities_enabled would be better 13:54:01 *** FooBar has joined #openttdcoop.devzone 13:55:17 <Hirundo> The percentages need conversion code ofc, also they might be more consistent with naming of industry vars 13:55:49 <Yexo> hmm, you're right 13:55:52 <Hirundo> "transported_last_month_pct_1" <- not sure how they'd fit in this scheme though 13:55:54 * Yexo was a bit too quick with adding this 13:56:05 <planetmaker> hm, there's also 'pct'? :-) 13:56:06 <Yexo> have to go now, will fix this tonight 13:56:54 <planetmaker> enjoy 14:06:12 *** hanf has quit IRC 14:10:02 <V453000> Ammler: I know, I do not even believe anyone would be interested in my sprites, but when pm starts telling you how he could do whatever he wants and I am not going to able to stop him, I am starting to wonder if the community which requires me to be community friendly is also friendly so to say 14:11:08 <planetmaker> choose a better community 14:12:05 <planetmaker> A license is exactly about that: stating what others can do and what not. And community-friendly simply means: the community can use the stuff as each sees fit 14:12:09 <planetmaker> what's unfriendly there? 14:12:56 <V453000> nothing at all 14:13:00 <V453000> your approach to suggesting is 14:13:13 <planetmaker> No. 14:13:22 <V453000> when the first thing you tell me I could not stop you if you liked, it does not feel too cooperative 14:13:29 <planetmaker> If you have a license which allows it, it cannot be unfriendly to go by the license 14:13:55 <V453000> I suppose at least telling the person might be nice 14:14:16 <V453000> eventually just asking in terms of good atmosphere 14:14:17 <planetmaker> that's what the licenses explicitly do not require 14:14:29 <V453000> I do not say agreement by law 14:14:35 <V453000> just discussion 14:14:48 <^Spike^> V now going to take a different example.. if i want to use/edit the linux kernel you want me to ask/tell everyone who worked on it that i'm doing so? 14:15:00 <V453000> no, certainly not 14:15:10 <^Spike^> i would be busy the first 2 years of my project notifying those people before actually doing so 14:15:44 <Terkhen> when a project is licensed under a gpl license or something similar... asking for permission is good but not required; giving credit is what is required 14:15:57 <Terkhen> a matter of manners :P 14:16:00 <V453000> yes, exactly my point Terkhen 14:16:31 <Rubidium> either you explicitly license someone to continue your work (won't work when you're dead), anything else basically gives others blanket rights to do as they see fit 14:16:44 <V453000> yes, I agree with that 14:16:48 <^Spike^> damn... wanted to try license stuff of all dead people.. :) 14:17:22 <planetmaker> Thank you V453000. Really thank you. You just showed how much you trust me 14:17:26 <planetmaker> I'll remember that 14:17:44 <Rubidium> you can say you would prefer that people ask you permission, but either that gets explained as: you may ask, but don't need to or as: you need to ask (which again fails upon death) 14:18:01 <V453000> planetmaker: it were your words that made me even consider that 14:18:06 <planetmaker> And thanks for taking a lesson as personal insult 14:18:46 <Rubidium> unless you write a license that grants e.g. GPL after your death, but not before... but that's making it still pretty difficult as you need to get legal proof of your death before anything can change 14:18:54 <planetmaker> Yes, I know that. Which is actually the point 14:19:27 <FooBar> I believe it's already common practice amongst NewGRF people to ask before using something, even if there's a license that doesn't require that. 14:19:42 <V453000> so, sorry for telling you that you said something which made me feel odd? seriously? 14:20:55 <FooBar> I don't know the rest of what lead to this discussion, so I'll be quiet now :) 14:35:09 <Ammler> V453000: planetmaker is more friendly than needed :-) 14:35:24 <Ammler> he does also ask, if not needed 14:35:59 <V453000> I know and believe that, I am just saying that the whole root of the discussion was not nice, is all 14:36:36 <Ammler> the point is that you need to define a license, so your stuff can be continued without you, that is all 14:36:37 <V453000> but yes, I am going to use GPL 14:36:54 <V453000> where should I put the license then< 14:36:56 <V453000> ? 14:37:48 <Ammler> add it to your repo, mention it in the readme 14:37:50 <^Spike^> well i don't know how newgrf ppl do it but as far as i've seen there is 1 file called LICENSE which has a full copy of the respected license in there... and the files have a certain header (last part not always) 14:38:30 <planetmaker> I call it license.txt, but yes 14:38:33 <^Spike^> but that is how mow SW developers do it i don't know how it is done in newgrf 14:38:36 <^Spike^> how* 14:38:40 <^Spike^> most* 14:38:51 <V453000> uhm :) cant add stuff to the repo now since I do not have tortoisehg established :| 14:38:54 <^Spike^> ..... better start gaming.... my fingers can't type anymore 14:39:08 <Ammler> V453000: yes, do it when you have 14:39:24 <V453000> ok :) I do not intend to stop on drawing anytime soon anyway 14:39:25 <Ammler> there is no need ot license unpublished stuff :-) 14:39:35 <Ammler> just do not release something without 14:39:40 <V453000> I could die, sure, but ... :) 14:39:40 <V453000> ok 14:40:01 <V453000> so until I release something it actually does not matter, right? 14:40:14 <Ammler> well, you have already stuff in the tickets 14:40:19 <Ammler> maybe forums, dunno 14:40:28 <Ammler> that is also a kind of release 14:40:33 <V453000> hmm :) 14:40:57 <planetmaker> well, simple. creating a project here means to choose a license 14:41:09 <Ammler> people in a opensource community tend to die fast ;-) 14:41:17 <planetmaker> :-) 14:41:25 <V453000> do they? :D 14:42:49 <^Spike^> or get locked up cause of murder... 14:43:02 <^Spike^> some ppl should know who i'm referring to :) 14:43:38 <Ammler> ^Spike^: I don't 14:43:46 <Ammler> who? 14:43:46 <^Spike^> ever heard of ReiserFS? :) 14:43:53 <Ammler> ah 14:43:55 <^Spike^> google Hans Reiser ;) 14:44:01 <V453000> ok, so let's say if nobody gives me in for dangerous mental illness and being nuts, I should not die that fast :P 14:44:13 <Ammler> reiser was once default fs on suse 14:44:17 <^Spike^> yep 14:44:24 <^Spike^> but was dropped cause development lacked 14:44:29 <^Spike^> when he got arrested 14:44:43 <Ammler> V453000: well, you can also get upset about the community :-P 14:45:07 <Ammler> then we should be sure, you can't take your work with you , if you leave :-P 14:45:26 <V453000> :D not that quickly I think 14:45:30 <V453000> (again) 14:45:35 <Ammler> :-D 14:45:37 <V453000> if ever 14:45:45 <Ammler> but you see, it could happen :-P 14:46:03 <V453000> well, yes, but then Mark comes from the grave and tells you many things that convince you 14:46:26 <Ammler> I mean, think about people like SAC or MB, who have much unreleased work which is lost, if they leave 14:47:50 <Ammler> and if you reuse TTD stuff, please do not tell someone 14:48:11 <V453000> :D 14:48:17 <V453000> I even won't need to 14:48:23 <V453000> but I just wanted to ask 14:53:32 <Ammler> oh, and just you know, your work on devzone is GPL, if you don't mention something else 14:53:55 <V453000> good :) 14:54:11 <Ammler> not sure, if planetmaker is aware about 14:54:36 *** StepanBarth has joined #openttdcoop.devzone 14:55:03 <Brot6> Central European Train Set - Feature #3045: Wagons - sprites (oberhuemer) @ http://dev.openttdcoop.org/issues/3045#change-7769 14:55:38 <Brot6> Central European Train Set - Feature #3045: Wagons - sprites (oberhuemer) @ http://dev.openttdcoop.org/issues/3045#change-7769 14:55:42 <planetmaker> well, Ammler :-) If the repo itself doesn't say so, it's at least fishy 14:56:13 <planetmaker> unless the repo creation script creates a repo and commits license.txt ;-) 14:56:23 <planetmaker> which would not be good either 14:56:48 <Brot6> Central European Train Set - Feature #3045: Wagons - sprites (oberhuemer) @ http://dev.openttdcoop.org/issues/3045#change-7769 14:56:56 <Ammler> no license file, no mention of a license = GPL 14:57:14 <Ammler> according to http://dev.openttdcoop.org 14:57:14 <FooBar> does it say that anywhere? 14:57:20 <FooBar> heh :) 14:57:33 <^Spike^> aka According to Ammler who made the frontpage? ;) 14:57:34 <Brot6> Central European Train Set - Feature #3045: Wagons - sprites (oberhuemer) @ http://dev.openttdcoop.org/issues/3045#change-7769 14:57:48 <planetmaker> well, we discussed that once upon a time 14:57:54 <Ammler> ^Spike^: well, I added that quite at start 14:57:58 <planetmaker> ^ 14:58:12 <FooBar> seeing that again, it has been stated there for a very long time now 14:58:12 <planetmaker> history will tell that easily :-) 14:58:30 <^Spike^> sometimes.. i would be hoping you guys don't take EVERY comment i make so serious :D 14:58:47 <V453000> :d 14:58:53 <Ammler> comments about license aren't fun :-P 14:59:03 <^Spike^> i wasn't commenting on the license :) 14:59:10 <^Spike^> i was commenting on the frontpage :D 14:59:17 <V453000> lack of beer is no fun either 14:59:19 <Ammler> :-) 14:59:21 <FooBar> often hard to tell if something is a joke or serious 14:59:30 <Brot6> Central European Train Set - Feature #3045: Wagons - sprites (oberhuemer) @ http://dev.openttdcoop.org/issues/3045#change-7769 14:59:33 <^Spike^> they should know me longer by now FooBar :) 14:59:35 <^Spike^> atleast 2 years :) 14:59:43 <^Spike^> if not they've missed something for 2 years :D 15:00:06 <FooBar> still, you can't be joking all the times :P 15:00:09 <Ammler> I guess, 2cctrainset < v2 and opensfx are the only non GPL projects 15:00:17 <^Spike^> true.. but then my lines lack smilies somehow :) 15:00:24 <^Spike^> and i know when to be serious aswell :) 15:00:26 <Ammler> maybe some dutch things 15:00:45 <FooBar> dutch stations maybe then, other dutch things are gpl as well 15:00:59 <Ammler> dutchtrainset might not be either 15:01:24 <FooBar> that particular repo contains some code by DJN and graphics by Purno. 15:01:39 <Ammler> purno only? 15:01:54 <FooBar> IIRC DJ Nekkid always uses GPL and Purno's graphics are GPL for quite some time now 15:01:54 <Ammler> then it can be GPL 15:02:15 <FooBar> The repo doesn't contain all sprites I believe 15:02:23 <Ammler> afaik, they once tried to cleanup the license, not sure, how well they proceed 15:03:06 <FooBar> oh wait, it contains a decoded dutchtrainset I wasn't aware of 15:03:17 <FooBar> so it's probably not completely GPL 15:04:09 <FooBar> the license thing they attempted was to get the set on bananas. They (unfortunatley) arrived at the most restrictive CC 15:05:42 <FooBar> whenever I get around starting recoding the set in NML the repo will be cleaned of old stuff and GPL'ed from there on 15:05:46 <Ammler> V453000: if you wanna solf a license issue, IMO the most valueable would be to make opensfx gpl :-) 15:06:02 <Ammler> then you would be hero :-P 15:06:43 <Ammler> then we can finally sell complete working openttd 15:07:12 <V453000> ... 15:07:12 <FooBar> sell? you mean "transfer copies for a nominal fee" :P 15:07:21 <Ammler> yes 15:07:24 <FooBar> maybe paid support is a good idea 15:07:38 <FooBar> with all these questions about why changing grfs ingame was removed :P 15:07:43 <planetmaker> :-D 15:07:57 <Ammler> that is already possible 15:08:00 <FooBar> "I can tell you the answer, but it's gonna cost you" :P 15:08:13 <V453000> :D 15:08:21 <Ammler> but afaik, you can't sell openttd cd with opensfx on it 15:08:23 <V453000> nasty idea 15:08:25 <FooBar> yes, thats true. But in that sense selling it is also already possible, just without the music 15:08:37 <planetmaker> music is fine. Sound is not 15:08:59 <FooBar> oh sound I mean, my mistake 15:09:48 <Ammler> FooBar: it wuld also fix some restrictrive repo issues like adding to debian default 15:11:04 <Ammler> so it is not just get me rich :-P 15:11:27 <FooBar> heh :) 15:11:49 <FooBar> I just checked, and the license indeed does not permit commercial use 15:12:24 <Ammler> the only open ticket at opensfx, iirc :-) 15:13:07 <V453000> Q: Is it possible to make the train set detect which base set is loaded and show different sprites in each case? 15:13:17 <planetmaker> yes, but good sound is hard to come by 15:13:27 <FooBar> V453000: no 15:13:31 <V453000> :( 15:13:31 <planetmaker> sound in midi format 15:13:37 <^Spike^> got sit with a mic next a rail track? :) 15:13:44 <^Spike^> or didn't mean that? :) 15:13:55 <FooBar> may lead to desyncs if you're not careful, therefore it was never implemented in the game 15:13:58 <V453000> well, at least I will draw less sprites :D 15:14:00 <planetmaker> would probably work. But you've got to produce about 60 different sounds 15:14:26 <^Spike^> just use static noise for most of them and say the wind ruined the sample :) 15:14:30 <V453000> I wanted to make toy wagons with red robots for TTD and yellow ducks for opengfx but I guess robots will have to suffice then :S 15:14:38 <planetmaker> :-P 15:14:39 <Ammler> V453000: I guess ser is good set to check how to handle that 15:15:00 <FooBar> V453000: I tend to make it a parameter setting to select what base set to support. Doesn't work really well with multiplayer (i.e. user's can't select what they want themselves), but works great for single player. 15:15:37 <V453000> I guess 15:15:43 <V453000> I had the same thought 15:15:56 <V453000> but yes, I wanted it the multiplayer way :P no matter 15:15:57 <FooBar> But depending on what you're trying to make just the OpenGFX sprites can work out fine with the TTD base graphics as well 15:16:27 <Ammler> I don't think it is worth to make different graphics depending on base set 15:16:34 <V453000> no, probably not 15:16:56 <FooBar> if it's "pasting on top of a ground sprite" it isn't too much work 15:16:58 <Ammler> I want both, robots and ducks :-P 15:17:06 <FooBar> but it indeed really depends on what you want 15:17:16 <planetmaker> you cannot query for a base set. Thus it's best to make as a set as compatible as possible, as independent as possible 15:17:47 <V453000> I guess I could make both 15:18:03 <V453000> and have them show both at the same time 15:18:11 <V453000> randomly in wagons 15:19:43 <FooBar> what are you planning to reuse from the base set anyways? 15:21:11 <V453000> nothing 15:21:43 <FooBar> oh, then there's no problem :) 15:22:29 <V453000> I thought I would use steel earlier, but when I put it in various views of the wagons it looked quite odd and I found it quite hard to make it rotated so I made my own instead 15:22:56 <FooBar> oh, one tip: if you make a printscreen of the openttd window to zoom in at some details in the graphics editor, don't try to close the sprite aligning window in the graphics editors as I just attempted. Didn't work :P 15:23:00 <V453000> and all those ducks and robots are in the base set itself so large that they would need gigantic wagons to fit in, so I have just some "pixel colonies" that remind them 15:25:26 <Brot6> Central European Train Set - Feature #2924: Prussian steam engines - sprites (oberhuemer) @ http://dev.openttdcoop.org/issues/2924#change-7770 15:25:46 <planetmaker> eh, FooBar? 15:26:07 <planetmaker> oh :-) 15:26:14 <FooBar> got it? :P 15:26:19 <planetmaker> needed to read it 3x. But yes 15:26:27 <FooBar> happens all the time when I make a printscreen 15:26:38 <V453000> common stuff :P 15:26:52 <FooBar> after saving the file I try to close the "window" which isn't a window but a picture of a window... 15:27:05 <Brot6> Central European Train Set - Feature #2924: Prussian steam engines - sprites (oberhuemer) @ http://dev.openttdcoop.org/issues/2924#change-7770 15:27:50 <planetmaker> yeah, happens :-) 15:29:45 <FooBar> little bit too often for my liking 15:30:27 <planetmaker> write a 'fix' for openttd with a config file option 15:30:46 <planetmaker> which prints over the resulting screenshot text like "sample. Only for eye's use" 15:30:54 <planetmaker> in big, red, bold letters ;-) 15:31:30 <planetmaker> hm... "Sample. For eyes only" is better ;-) 15:31:53 <FooBar> "Warning. Buttons have been disabled" 15:32:28 <FooBar> but usually I just hit printscreen key. Don't think OpenTTD can influence that? 15:33:32 <FooBar> But maybe just photoshop should recognise X-buttons in pictures and then offer the user to close the actual picture :P 15:34:26 <FooBar> It already recognises US money (and tells it may be illegal what you're doing), so it shouldn't be too hard for them to add such a feature 15:37:29 *** StepanBarth has quit IRC 15:38:35 *** StepanBarth has joined #openttdcoop.devzone 16:42:48 <Ammler> FooBar: or use the openttd screenshot feature 16:42:57 <planetmaker> :-) 16:43:10 *** hanf has joined #openttdcoop.devzone 16:43:29 <planetmaker> I ususally use that... resize openttd to the proper size directly and then use the console to give it a proper name at the same time 16:44:32 <FooBar> I do that when I want to save the screenshot. Today I didn't want to save it, just zoom in. As I had photoshop open anyways, prtsc, ctrl+n, enter, ctrl+v was muchquicker 16:44:42 *** frosch123 has joined #openttdcoop.devzone 16:44:46 *** LordAro has joined #openttdcoop.devzone 16:44:59 <planetmaker> zoom in? doesn't your OS support zoom-in directly without screenshot? 16:45:26 <FooBar> certainly, but also that is more effort when I have the graphics program open 16:45:52 <planetmaker> hm... ctrl+fn+scroll for me :-) 16:46:07 <planetmaker> which is about the same as fn+cmd+f3 ;-) 16:46:45 <planetmaker> which would leave me with the need to still open the file 16:46:49 <FooBar> I don't think I have a shortcut configured 17:08:13 <LordAro> how would i go about downloading just the etxra part of ogfx? 17:08:45 <planetmaker> uhm... what do you mean? Source? grf? 17:08:50 <LordAro> source 17:08:55 <planetmaker> you don't 17:09:10 <planetmaker> well, the nfo is in the bundle's folder published 17:09:19 <planetmaker> for every nightly. 17:09:43 <planetmaker> But the sensible way is to get a checkout of OpenGFX and use the not pre-processed source code files 17:10:25 <LordAro> sprites/ogfxe_extra.pnfo ? 17:10:39 <planetmaker> yes. Though that's a list of files which get included 17:10:47 <planetmaker> all files are in sprites/nfo/extra 17:11:17 <LordAro> ah, that makes life easier 17:11:29 <planetmaker> what do you plan? 17:11:34 <LordAro> nad all the png are in sprites/png/extra ? 17:11:37 <LordAro> 32bpp_extra 17:11:48 <planetmaker> no. the pngs are where the source code files tell you 17:11:51 <LordAro> i'm basically rewriting it :) 17:11:55 <planetmaker> they're used accross the different grfs 17:12:04 <planetmaker> thus only ordered thematically 17:12:10 <planetmaker> why re-write? 17:12:24 <LordAro> because its a complete mess :) 17:12:32 <planetmaker> uhm... is it? 17:13:02 <LordAro> well, the makefile is at least - files don't get added when they're supposed to 17:13:19 <planetmaker> ? 17:13:27 <LordAro> and i suspect that the .pnfo file is out of date 17:13:34 <planetmaker> ... 17:13:47 <planetmaker> OpenGFX' pnfo is not out of date :-) 17:14:06 <LordAro> *.pnfo file of 32bpp_extra ;) 17:14:06 <planetmaker> you make quite strong claims here 17:14:31 <planetmaker> ah, ok, that I don't know 17:14:56 <LordAro> yeah, i'm not silly enough to claim that opengfx is outofdate :3 17:17:33 <V453000> How exactly does the sprite offset behave? I want to make coordinates of a sprite ... I know x, y, height and width, but I do not know what values should the offset have ... is there some info to read on that somewhere? 17:18:19 <planetmaker> LordAro: what are the symptoms? 17:19:19 <LordAro> well, when i try to add the extra sprites for the toolbar, nothing changes :) 17:19:34 <planetmaker> toolbar? 17:19:40 <planetmaker> they might not all be extra. Only some 17:20:15 <LordAro> i know, i think its just the 'fast forward' button and the 'level land' button 17:21:22 <LordAro> at least, they're the only ones with new sprites 17:22:04 <FooBar> V453000: start with negative of what half the width/height. Then check ingame and use the ingame sprite aligner to adjust 17:22:09 <Brot6> firs: update from r2582 to r2584 done - http://bundles.openttdcoop.org/firs/nightlies/r2584 17:22:35 <FooBar> the offsets basically define where the sprite is drawn ingame 17:22:45 *** Zuu has joined #openttdcoop.devzone 17:23:31 <hanf> FooBar: where is the origin for sprites 17:23:32 <planetmaker> LordAro: there's a file which deals with all the GUI sprites 17:23:48 <planetmaker> they're defined in there 17:24:05 <planetmaker> it should be named like ...gui...pnfo 17:24:08 * LordAro checks the .pnfo files of 32bpp_extra again 17:24:16 <FooBar> hanf: for vehicles it's the middle of their bounding box. For objects/buildings I believe it's the lower north of the bounding box 17:24:24 <planetmaker> at least in OpenGFX. But if it wasn't changed, it should be there, too 17:24:40 <hanf> FooBar: what do you mean by lower north? 17:24:41 <planetmaker> It might be that one needs to define all GUI sprites or none... 17:24:43 * planetmaker checks 17:25:26 <FooBar> hanf: imagine a 3D box. Then stay on the floor of that box and walk to the furthest corner 17:25:44 <hanf> aha, I see. thanks 17:25:50 <FooBar> hanf: here's some more information: http://newgrf-specs.tt-wiki.net/wiki/PalettesAndCoordinates#Coordinates 17:26:24 <planetmaker> yes, you can define also GUI sprites with offsets, LordAro 17:26:29 <Brot6> ogfx-rv: update from r120 to r122 done - http://bundles.openttdcoop.org/ogfx-rv/nightlies/r122 17:26:33 <planetmaker> http://newgrf-specs.tt-wiki.net/wiki/Action5 <-- 17:26:49 <planetmaker> action 05, type 95, if you don't want to re-define all GUI sprites 17:26:58 <planetmaker> otherwise type 15 17:27:01 <Rubidium> you might be the first to actually use it though ;) 17:27:06 <planetmaker> :-) 17:27:22 <planetmaker> Not sure about bigGUI NewGRF 17:27:29 <Brot6> OpenGFX+ Landscape - Bug #3050 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/3050 17:27:30 <planetmaker> it might or might not 17:27:34 <Brot6> Following repos didn't need a nightlies update: ogfx-trains (r252), narvs (r52), bros (r52), ogfx-industries (r123), opengfx (r733), ailib-tile (r16), foobarstramtracks (r23), transrapidtrackset (r28), 2cctrainset (r750), cets (r145), ailib-list (r32), opensfx (r97), ttdviewer (r34), worldairlinersset (r672), heqs (r640), openmsx (r97), basecosts (r25), nutracks (r208), nml (r1663), water-features (r51), 32bpp-extra (r40), manindu (r7), 17:27:34 <Brot6> newgrf_makefile (ERROR r313), ailib-direction (r17), vactrainset (ERROR r1), ailib-common (r21), snowlinemod (r49), dutchtramset (r87), ai-admiralai (r75), swisstowns (r22), metrotrackset (r56), dutchroadfurniture (r29), spanishtowns (r10), frenchtowns (r6), grfpack (r279), fish (r684), ttrs (r36), ogfx-trees (r51), swedishrails (r206), grfcodec (r833), ai-aroai (r49), german-townnames (r34), smts (r19), chips (r143), belarusiantowns 17:27:36 <Brot6> (r8), indonesiantowns (r41), ailib-string (r29), airportsplus (r145), comic-houses (r71) 17:28:11 <planetmaker> hm, Ammler, can we skip the "didn't need an update" messages? 17:28:35 <Brot6> newgrf_makefile: compile of r313 still failed (#3037) - http://bundles.openttdcoop.org/newgrf_makefile/nightlies/ERROR/r313 17:29:21 <Brot6> vactrainset: compile of r1 still failed (#3044) - http://bundles.openttdcoop.org/vactrainset/nightlies/ERROR/r1 17:29:56 * LordAro is scared of nfo 17:30:27 <planetmaker> LordAro: You could write in in NML alternatively 17:30:53 <planetmaker> http://newgrf-specs.tt-wiki.net/wiki/NML:Replace_new_sprites 17:31:02 * Yexo would like a testcase for 32bpp sprites with NML 17:31:06 <planetmaker> :-) 17:31:06 <LordAro> thats also what i was thinking, but i'd have to convert most of ogfx_etxra to nml, yes? 17:31:12 * planetmaker too 17:31:29 <planetmaker> LordAro: My guess rather is 'all' than 'most' 17:31:45 <planetmaker> But that might be interesting... 17:32:01 <planetmaker> And might be ported back to OpenGFX at some stage 17:32:24 <planetmaker> I'm still somewhat hesitant to port OpenGFX as it doesn't give much advantage but is HUGE work 17:32:29 <LordAro> there seems to be a little here http://dev.openttdcoop.org/projects/opengfx/repository/show/sprites/nml/extra 17:32:34 <Yexo> LordAro: only the parts of ogfx_extra that are used by 32bpp sprites 17:32:35 <planetmaker> but the part which would gain most is the extra newgrf 17:32:55 <planetmaker> You're right, LordAro 17:33:19 <planetmaker> But that's a part you can safely ignore. It's only eye candy, providing different sprites for the same vehicles in different climates 17:33:52 <planetmaker> unless you have climate-specific sprites for the same wagons in 32bpp, too 17:34:03 <LordAro> don't believe so 17:38:00 <planetmaker> But as Y exo suggested, writing a 32bpp extra grf from scratch might actually be a nice solution 17:39:19 <LordAro> so i would need a combination of http://newgrf-specs.tt-wiki.net/wiki/NML:Replace_new_sprites and http://newgrf-specs.tt-wiki.net/wiki/NML:32bpp_sprites ? 17:39:36 <Yexo> yes 17:39:37 <planetmaker> yes 17:40:40 <Yexo> if you need an example give me some 32bpp sprites and I'll create it 17:45:35 <LordAro> great :) http://jupix.info/openttd/gfxdev-repo/files/GUI-Toolbar%20and%20Selectors.tar - the toolbar sprites are in there, 3755.png and 3756.png 17:45:55 <Yexo> The requested URL /openttd/gfxdev-repo/files/GUI-Toolbar and Selectors.tar was not found on this server. 17:46:08 <LordAro> http://www.tt-forums.net/download/file.php?id=81820 17:47:40 <LordAro> hang on, you're right 32bpp-ez project is a mess, i'll check before i post a link next time and i'll find a better one :) 17:47:55 <Yexo> LordAro: the files in "sprites/trg1r/" don't need the extra grf at all 17:48:34 <LordAro> am aware of that, it was just the original tar file GeekToo posted 17:48:38 <Yexo> only the fastforward button (sprites/openttd/57.png) needs an _extra.grf file 17:49:12 <planetmaker> hm, is here a 32bpp repo on the devzone? 17:49:17 <planetmaker> with the sprites? 17:49:38 <Yexo> none with all sprites available 17:49:42 <Yexo> that is one of the problems 17:50:12 <planetmaker> yeah... I wonder whether it's worth to clone OpenGFX and then just additionally add the 32bpp 17:50:18 <planetmaker> It's what I'd do 17:50:50 <planetmaker> it'd leave users always with fallback sprites as long as the 32bpp isn't finished 17:50:59 <planetmaker> and one could sync it from time to time 17:51:08 <Yexo> but you don't need fallback sprites as long as 32bpp sprites isn't finished, you already have them: your 8bpp baseset 17:51:20 <planetmaker> true. 17:51:42 <planetmaker> Thus it could be a NewGRF. 17:51:57 <planetmaker> The problem is that the extra grf cannot be static, if declared as NewGRF due to the rivers 17:52:16 <Yexo> perhaps leave rivers out for now then 17:53:08 <Yexo> hmm, that means the normal extra grf is not static either? that means it can be desynced due to incompatible basesets 17:53:40 <planetmaker> base set extra grf are used as static, no matter what 17:53:50 <Yexo> that isn't the point 17:54:01 <Yexo> it should be possible to load it as normal static grf (apart from the grfid maybe) 17:54:24 <Yexo> if that's not possible (due to rivers), it means it has features that can desync openttd if played with different basesets 17:54:26 <planetmaker> That means I cannot add rivers really in the current form 17:54:51 <Yexo> I'm not saying it _will_ cause desyncs if you use any of those features 17:55:15 <Yexo> I already know there is some code like that in the extra grf (specifying vehicle overrides for some old newgrfs) 17:55:22 <Yexo> which is _bad_ 17:55:55 <planetmaker> the extra grf uses (in nfo terms) actionA for a number of sprites. Which is no issue 17:56:04 <planetmaker> and for rivers it uses the normal action1/2/3 17:56:39 <planetmaker> and of course there are action7/9 for climate-specific jumps 17:57:26 <Yexo> the action7/9 are no problem 17:57:39 <Yexo> the action1/2/3 might be, for rivers it's probably not, but for all other features it would be 17:58:21 <planetmaker> The point is, without that, rivers cannot be implemented. And even the openttd.grf uses some river code in the same way 17:58:29 <planetmaker> for all others it would 17:58:36 <planetmaker> but that's not done 17:59:20 <Yexo> planetmaker: I'm not saying this specific case is a problem, if it's not, action1/2/3 for rivers should probably be allowed for static grfs 17:59:38 <planetmaker> I wonder if randomaction2 for rivers can be allowed 17:59:54 <planetmaker> sounds problematic... though it's used 17:59:59 <planetmaker> for ages 18:00:15 <frosch123> they have no triggers 18:00:24 <frosch123> that's the only reason why they work 18:00:31 <planetmaker> ah, ok 18:00:44 <planetmaker> so, we must not add triggers :-) 18:00:57 <planetmaker> it would destroy our happy world of base set rivers 18:01:18 *** StepanBarth has quit IRC 18:01:45 *** StepanBarth has joined #openttdcoop.devzone 18:09:46 <Yexo> LordAro: http://paste.openttdcoop.org/show/570/ this should work 18:17:30 <Ammler> LordAro: nml is also the best portable for 32bpp, no need of those ugly bat files or what people use 18:18:01 <planetmaker> indeed :-) 18:18:13 <planetmaker> and no need to learn pngcodec 18:18:15 <Zuu> LordAro: You quited yesterday only some 10-30 minutes before I uploaded the screenshot :-p 18:18:33 <planetmaker> *quit ;-) 18:19:32 <Ammler> LordAro: also I would make a whole base set, not just the extra 18:20:04 *** StepanBarth has quit IRC 18:20:29 <Ammler> hmm, planetmaker, this is acutally a good reason to port opengfx to nml 18:20:40 <Ammler> so it could be forked for 32bpp base set 18:20:41 <planetmaker> I might be a nice idea to revive http://dev.openttdcoop.org/projects/opengfx32bpp 18:20:42 <Yexo> <Ammler> LordAro: also I would make a whole base set, not just the extra <- I'd say that's a bad idea 18:20:50 <Yexo> there is no good reason to port the whole baseset 18:20:51 <planetmaker> I've never seen any activity there 18:21:07 <Yexo> the sprite numbers for the "normal" baseset grfs are fixed 18:21:25 <Ammler> Yexo: the issue is that extra grf isn't static, afaik, is it? 18:21:50 <Yexo> but you don't need the complete extra grf 18:21:58 *** hanf has quit IRC 18:22:13 <Yexo> as for the few parts in there that aren't static (is that more than rivers?), that should be fixed in openttd so they can be loaded in a static grf 18:22:28 <planetmaker> it's to my knowledge only rivers which break it 18:23:22 <Ammler> the override might too 18:23:30 <planetmaker> there are overrides?! 18:23:38 <Yexo> yes, but you wouldn't want to copy that in the 32bpp extra grf at all 18:23:40 <Ammler> yes, around 3 18:23:56 * planetmaker is surprised 18:24:08 <Ammler> yeah it was silly 18:24:24 <Ammler> kind of mistabke, iirc :-) 18:24:45 <planetmaker> where are they? 18:25:08 <Ammler> at the end 18:25:32 <Ammler> I might not have donated a own file to those as I splitted :-) 18:25:33 <Yexo> for openttd in trunk/media/extra_grf/overrides.nfo 18:25:38 <planetmaker> extra-openttd-overrides.pnfo 18:25:47 <planetmaker> hm, also? 18:25:51 <Ammler> oh, I did :-) 18:26:05 <Yexo> planetmaker: of course, it has to be in both basesets 18:26:16 <planetmaker> a very readable override sprite... :S 18:26:18 <Yexo> having it in one and not in the other will cause a desync as soon as one of those overrides is in effect 18:26:19 <Ammler> we wouldn't have those in opengfx else :-P 18:26:35 <Yexo> which is exactly why they shouldn't be in the extra grf at all 18:27:02 <planetmaker> Yexo: sure. I'm just surprised to find them there and never noticed before (or forgot) 18:27:04 <Yexo> but now that they are they can't be removed again (unless those 3 overrides are hardcoded in openttd) without causes the same problem 18:27:17 <Ammler> not really 18:27:34 <planetmaker> yeah... once there, always there :S 18:27:37 <Ammler> wouldn't hurt, just might cause some issues for some saves 18:27:47 <Ammler> but no crashes or so 18:27:51 <planetmaker> it would cause desyncs 18:27:52 <Yexo> Ammler: multiplayer games with people using different basesets 18:28:22 <Ammler> openttd does alert, if you use uncompatible baseset 18:28:30 <Ammler> doesn't? 18:28:31 <Yexo> uhm, no? 18:28:33 *** Lakie` has joined #openttdcoop.devzone 18:28:42 <Yexo> there is no such thing as an "incompatible baseset" 18:28:53 <Yexo> openttd only alerts for "old" basesets that miss some features 18:29:00 <Yexo> s/features/sprites/ 18:29:02 <Ammler> exacty 18:29:10 <Yexo> overrides like these is no such thing 18:29:21 <Yexo> if openttd were to check for exactly these 3 overrides it might as well hardcode them 18:29:22 <Ammler> :-) 18:32:12 <Ammler> I wonder, why opengfx needs to provide the extra grf at all 18:32:25 <Ammler> since openttd.grf is shipped with openttd 18:32:36 <Yexo> to provide sprites with the same style as the rest of the baseset? 18:32:46 <Ammler> yes of course 18:32:49 <Zuu> ... hmmm... When OpenTTD loads a NewGRF airport, it computs AirportSpec::size_x and size_y as the smallest boundingbox that works for all layouts. Eg the bounding of a 2x8 airport with 4 rotations will be 8x8. 18:32:52 <Ammler> but why the whole rest 18:33:05 <Yexo> and since openttd.grf changes between versions, if you wouldn't ship an extra grf with opengfx your releases would only be compatible to a single version of openttd 18:33:14 * Zuu starts OpenTTD with a debugger to see if that is true 18:33:14 <Yexo> highly annoying when updating openttd breaks it 18:33:29 <Yexo> Zuu: that shouldn't be true 18:33:44 <Yexo> for a 2x8 airport it should be size_x=2, size_y=8 18:33:48 <Ammler> Yexo: not if openttd wouldn't requite the baseset providing it 18:34:02 <Yexo> but openttd requires the extra grf to run 18:34:11 <Yexo> it's an essential part of the baseset 18:34:12 <Zuu> Yexo: Even if there is both a 2x8 and a 8x2 layout? 18:34:22 *** Lakie has quit IRC 18:34:28 <Ammler> Yexo: but it could load openttd.grf always 18:34:29 <Yexo> Zuu: if the 8x2 layout has a rotation then yes, even in that case 18:34:39 <Ammler> nad handle extra grf of basesset like a newgrf 18:34:45 <Ammler> (static newgrf) 18:34:50 <Yexo> Ammler: suggest what you like, the discussion has gone way off-topic and is going nowhere 18:35:19 <Zuu> Still, it will break if one rotation is 2x8 and the other is 10x3. 18:35:28 <Ammler> Yexo: sorry :-P 18:35:33 <Zuu> Something that is possible according to planetmaker. 18:35:39 <Yexo> Zuu: in that case size_x=3 and size_y=10 18:36:00 <Yexo> assuming the 10x3 is DIR_E or DIR_W and the 2x8 is DIR_N (or DIR_S) 18:36:35 <Ammler> (was not meant as suggestion) 18:37:33 <Zuu> Now, if you call eg. GetMinimalAirportDistanceToTile for that airport, even if that function is fixed to take a view argument, it will break as all views are not of the same size. 18:39:16 <Zuu> Assuming that we want to handle airports using a bounding box and not iterate through all tiles and compute the distance. 18:39:48 <Yexo> Zuu: hmm, yes 18:40:06 <Yexo> question remains in that case: do we really want to fix that by allowing differnt-sized layouts or just forbid that in the specs? 18:40:28 * Rubidium wonders how easy/difficult it would be to load a data NewGRF which contains those 3 overrides 18:40:43 <Rubidium> but also other stuff such as the 2cc colour remap 18:40:43 <Yexo> why would that be hard? 18:40:59 <Yexo> ah, to split that from the basesets? 18:41:21 <Rubidium> and... here comes the hardest bit: the data from quite a bit in tables/* 18:41:27 <Zuu> Yexo: Fixing it in the spec now sounds like a very easy solution :-D 18:42:23 <Zuu> However, if the performance hit of iterating all tiles and compute distance is acceptable, that will benefit the handling of irregular airports. 18:42:56 <Yexo> it might be 18:43:01 <Yexo> depends on where that function is called 18:43:15 <LordAro> "[19:09:28] <Yexo> LordAro: http://paste.openttdcoop.org/show/570/ this should work" <-- thanks :) but how would i go about 'filling in the proper sprite in 8bpp' ? (remember, i have very little clue about nml/grf making in general 18:43:33 <Yexo> copy the definition from opengfx 18:44:34 <LordAro> but what would that contain? 18:46:28 <Yexo> sorry LordAro, I don't have time for this now 18:47:14 <LordAro> :( 18:47:19 <LordAro> anyone else? :) 18:47:56 <LordAro> ah, i think i may have found it 18:48:02 <LordAro> http://newgrf-specs.tt-wiki.net/wiki/NML:Realsprites 18:48:03 <planetmaker> use what OpenGFX uses 18:48:06 <planetmaker> yes 18:48:31 <LordAro> ..but which 'format' should i use? 18:50:08 <planetmaker> most often the 1st, 3rd or 4th is what you want 18:50:31 <LordAro> opengfx just uses templates, which...i can;t be bothered with :) 18:50:43 <planetmaker> you don't need to 18:50:49 <LordAro> good :) 18:51:04 <LordAro> ok, how would i know which of those 3 'formats' to use? 18:51:35 <Zuu> I've looked up the callers for the three functions that I've found are affected by not taking a view as argument. See comment: http://bugs.openttd.org/task/4764 18:51:53 <Zuu> To me it looks like none of these are very performance critical. 18:51:53 <planetmaker> I guess in the extra grf compression never matters and cropping neither. 18:52:23 <planetmaker> thus... a normal sprite call: [x, y, width, height, offset_x, offset_y, filename] 18:52:43 <Zuu> Eg. nothing that happens at each tick, at each day at each .. 18:54:06 <planetmaker> if all sprites are from the same filename... it suffices to use the one in the replacenew call 18:54:45 <Zuu> But, I wonder how the station coverage might be affected if an airport supply two different-sized layouts. 18:55:07 <Zuu> Or supply the wrong DIR_X flag. 18:55:32 <planetmaker> Zuu: the station coverage should extend from the actual tiles of an airport. Should :-) 18:55:54 <Yexo> Zuu: that doesn't matter, for station coverage only the actual tiles are counted 18:55:57 <planetmaker> what does the highlight rectangle say? 18:56:06 <Yexo> Should :-) <- and does 18:56:07 <Zuu> The highlight rectangle is fine 18:56:17 *** andythenorth has joined #openttdcoop.devzone 18:56:24 <Yexo> the highlight rectangle might be off in that case 18:56:37 <Zuu> I'm just brainstorming if I've found all functions/areas that might not yet support views. 18:56:49 <Yexo> Zuu: note that providing the wrong DIR_X flag will also break the statemachine 18:57:11 <Zuu> Good, then it should be spotted and fixed by the NewGRF authors :-) 18:57:40 <LordAro> planetmaker: thanks 18:59:01 <LordAro> on http://newgrf-specs.tt-wiki.net/wiki/NML:Replace_new_sprites should it be [, <offset>] ? that's the sprite number is it not? 18:59:32 <Yexo> no, it's not 18:59:43 <planetmaker> extra grf has no specific sprite numbers 18:59:44 <Yexo> it's the offset within the block 18:59:46 <planetmaker> ^ 18:59:59 <Yexo> those numbers are not documented anywhere 19:00:12 <LordAro> that's... confuzzling 19:00:22 <Yexo> see openttd source, table/sprites.h, where you see SPR_IMG_FASTFORWARD = SPR_OPENTTD_BASE + 90; 19:00:31 <Yexo> that means that "offset" is 90 for the fastforward image 19:00:53 <planetmaker> see OpenGFX' source :-) 19:05:42 <LordAro> i can't find any reference to '90' on ogfx's source (http://dev.openttdcoop.org/projects/opengfx/repository/entry/sprites/nfo/extra/extra-openttd-gui.pnfo#L101) 19:06:08 <Brot6> clientpatches: compile of r22908 still failed (#2964) - http://bundles.openttdcoop.org/clientpatches/testing/ERROR/r22908 19:07:47 <Yexo> Zuu: there are no speed problems with actually calculation the distance to the closest tlle 19:08:07 <Yexo> so in my opinion that is the best solution 19:08:43 <planetmaker> LordAro: you won't find it as OpenGFX replaces all GUI sprites, thus no offset is ever used 19:08:54 <planetmaker> it'll simply be the 90s in the list of GUI sprites defined there 19:09:04 <Zuu> Yexo: I'll make a patch with that solution 19:09:35 <Yexo> as for your patches: adding a new parameter to an existing function can't be done 19:09:47 <Yexo> squirrel doesn't support overloading C++ functions (or overloading in general?) 19:09:58 <LordAro> planetmaker: 101-9 = 92... so yes :) 19:10:28 <Zuu> Thus AIAirport::BuildAirport will have to be renamed. 19:10:41 <Yexo> yes 19:11:19 <Zuu> At least, most functions that otherwise would be affected are moved to AIAirportType :-) 19:11:50 <Yexo> in that case it's no problem to add a parameter 19:11:53 <Zuu> Oh, and I think I have forgoten to do all necessary changes to the compat layer files. 19:12:01 <Brot6> openttd-vehiclevars: update from r22903 to r22908 done - http://bundles.openttdcoop.org/openttd-vehiclevars/testing/r22908 19:13:25 <Brot6> serverpatches: compile of r22908 still failed (#2966) - http://bundles.openttdcoop.org/serverpatches/testing/ERROR/r22908 19:13:42 <Ammler> hmm, offsets might be used for hte bigger OpenTTD letters 19:14:13 <Ammler> or not, as not every feature supports offset, dunno 19:15:16 <Brot6> 32bpp-ez-patches: compile of r22908 still failed (#2446) - http://bundles.openttdcoop.org/32bpp-ez-patches/testing/ERROR/r22908 19:19:37 <Yexo> Zuu: I see no reason for ai_airport.hpp to include ai_airporttype.hpp (the cpp files needs to include it, but the .hpp doesn't) 19:19:43 <Yexo> file airport-api-split.patch 19:20:17 <Yexo> and that file needs to add a lot to the compat_*.nut files 19:20:30 <Zuu> Indeed 19:20:32 <Zuu> Thanks 19:21:25 <Yexo> ::AirportSpec::Get(type)->fsm <- AFAIK (but need to check to be sure) fsm is only !=NULL for default airports and newgrf airports that override the default ones 19:23:04 <Zuu> (I just collect your comments now, and will look into them later) 19:23:49 <Yexo> about airport-type-api-extension.patch in general: the API looks sane, the implementation depends too much on the current state 19:23:58 <Yexo> I'm a bit worried it only makes newgrf airports harder 19:24:50 <Yexo> in AIAirportType::IsValidAirportView: I'd rather see the check reversed, so "airport_view < AirportSpec::Get(airport_type)->num_table" instead of "AirportSpec::Get(airport_type)->num_table > airport_view" 19:25:26 <Yexo> ai_airportviewlist.cpp has a commented-out #include, that line should be removed 19:27:11 <Yexo> and given the current state, (if the airport is valid, all views are valid and always numbered 0..num_view-1) I wonder how useful AIAirportViewList is instead of a function AIAirportType::GetNumViews() 19:30:27 <Terkhen> planetmaker: I'm not sure if sharing cargo sprites between farm supplies and vehicles is good 19:30:40 <Terkhen> I don't play with any set that includes "vehicles", but that sprite does not seem appropiate 19:32:17 <planetmaker> hm? 19:35:22 <planetmaker> what do you mean, Terkhen? 19:35:41 <planetmaker> that they should have different sprites? 19:35:49 <planetmaker> well. Possibly and ideally, yes 19:36:18 <Terkhen> sorry, I usually speak my mind disregarding context :) 19:36:20 <Terkhen> http://dev.openttdcoop.org/projects/ogfx-trains/repository/changes/src/gfx/flatbed/rail_flatbed_vehicles_temperate.png 19:36:22 <Terkhen> I mean that sprite 19:36:36 <planetmaker> maybe car sprites can be scratched from the general vehicle newgrf for use with town car AI 19:36:38 <Terkhen> I was wondering if Zephyris would let us use the sprites from generic cars instead 19:36:51 <Terkhen> yes, that :P 19:36:51 <planetmaker> yeah. Might be good 19:37:34 <planetmaker> it was at that more a "better show tractors than containers when transporting 'vehicles'" 19:38:08 <Terkhen> that's true, yes :) 19:39:11 <planetmaker> especially also since in ECS one of the main recipients for 'vehicles' are mines and alike 19:39:17 <planetmaker> similar to ensp in FIRS 19:41:23 <Terkhen> oh, really? 19:41:29 <Terkhen> then the current sprite makes sense 19:42:22 <planetmaker> I cannot say for sure now whether there are other destinations, too 19:43:42 <Terkhen> as long as it makes sense... no need for additional work :P 19:43:44 <Terkhen> I was mislead 19:51:46 <Zuu> Hmm GetMinimalAirportDistanceToTile is called once for each town by AirportGetNearestTown, which an AI in theory could call 10 000 times each tick. 19:52:44 <Zuu> In the debug build I get a 0.5 second freeze or so when that happens (I think) or there is something else AI-related that freeze the game. 19:53:17 <Yexo> Zuu: there is an optimization so it doesn't call GetMinimalAirportDistanceToTile for towns that are too far away 19:53:52 <Zuu> Oh, yes I have even looked at that code and yet forgot it :-) 20:03:58 *** JVassie has joined #openttdcoop.devzone 20:08:24 <Zuu> So what is left for an AI to "abuse" is to call GetAirportNoiseLevelForTown 10 000 times in a tick 20:08:56 <Zuu> Which would call ManhattanDistance for 10 000 * [airport tile count] times. 20:09:12 <Yexo> an AI author that does that deserves to be slapped :p 20:09:18 <Zuu> DistanceManhattan* 20:10:30 <Zuu> Well, not 10 000 times, but a typical thing for an AI that looks for a placement for an airport to do would be to valuate a tile list with that function. 20:12:07 <Zuu> In the meantime, I've uploaded a patch to FS#4764 20:14:44 <Yexo> in GetMinimalAirportDistanceToTile there is some extra whitespace (the line after mindist=dist; 20:15:23 <Yexo> and an "assert(layout < as->num_table);" at the top of that function would be nice imo 20:15:24 <Zuu> Hmm, I tried to do /+.* $ in the patch but didn't find it. 20:15:48 <Yexo> it's tabs, not spaces 20:16:03 <Zuu> Oh, slap in my face for not using \s :-D 20:16:08 <Yexo> or maybe that assert is better in GetAirportNoiseLevelForTown and/or AirportGetNearestTown 20:18:51 <Yexo> looks good, thanks :) 20:18:57 <Yexo> will commit tomorrow or this weekend 20:19:46 <Zuu> Putting the assert in both callers is perhaps better as it can be done once and not inside any loop. 20:20:05 <Zuu> /any loop/town loop/ 20:20:40 <Zuu> Do you have any use for a new patch or did you already fix these things locally? 20:21:02 <Zuu> I've just made the fixes here, so I can just upload it. 20:21:51 <Yexo> please upload a new patch 20:21:55 <Yexo> I haven't even applied it yet 20:25:24 <Zuu> Find it done :-) 20:26:32 <Zuu> I will look through your comments on the AI stuff and reply to those points But, I think that I will save that for tomorrow. 20:27:06 <Rubidium> Zuu: without reading anything... what happens to airport/noise distance when the tile/town is within the irregular airport? 20:27:32 <Yexo> distance = 0? 20:27:37 <Zuu> Rubidium: It checks that tile as well and discard it because it is further away 20:27:57 <Zuu> Oh sorry 20:28:16 <Zuu> If you mean that the tile to compare against airport location is within an airport, the result is zero. 20:28:30 <Yexo> in fact it behaves better than before 20:28:48 <Yexo> hmm, no, it did the same already 20:29:22 <planetmaker> nice screenshots for ogfx+rv, Terkhen :-) 20:29:30 <Terkhen> thanks :P 20:29:44 <Zuu> If the tile layout is guaranteed to be in a certain order, someone clever might be able to speed up the loop by skip some tiles under certain conditions. 20:30:09 <Yexo> the order is not set 20:31:04 <Rubidium> just assume the worst possible order ;) 20:31:40 <Zuu> :-) 20:53:58 *** hanf has joined #openttdcoop.devzone 20:57:02 <Brot6> OpenGFX+ Airports - Feature #3031 (Closed): Todo for release 0.3.0 (yexo) @ http://dev.openttdcoop.org/issues/3031#change-7771 20:59:54 <andythenorth> good night 21:01:28 <Brot6> OpenGFX+ Airports - Feature #3051 (New): Reuse (part of) Combined Airport Set V0.5 (yexo) @ http://dev.openttdcoop.org/issues/3051 21:05:27 <Terkhen> good night andythenorth 21:06:46 *** andythenorth has left #openttdcoop.devzone 21:07:50 <Brot6> Dutch Road Furniture - Revision 30:8a16c21e1e19: Feature: median and third lane for motorways (foobar) @ http://dev.openttdcoop.org/projects/dutchroadfurniture/repository/revisions/8a16c21e1e19 21:09:43 <Brot6> OpenGFX+ Airports - Feature #3051: Reuse (part of) Combined Airport Set V0.5 (planetmaker) @ http://dev.openttdcoop.org/issues/3051#change-7772 21:12:36 <Brot6> OpenGFX+ Airports - Feature #3051: Reuse (part of) Combined Airport Set V0.5 (yexo) @ http://dev.openttdcoop.org/issues/3051#change-7773 21:14:38 <Brot6> OpenGFX+ Airports - Feature #3051: Reuse (part of) Combined Airport Set V0.5 (planetmaker) @ http://dev.openttdcoop.org/issues/3051#change-7774 21:35:59 *** LordAro has quit IRC 21:41:04 *** FooBar has quit IRC 21:43:11 *** ODM has quit IRC 21:47:20 *** frosch123 has quit IRC 22:05:07 <Brot6> Unrealistic Trainset - Feature #2880: Maglev Flatbed #01 (V453000) @ http://dev.openttdcoop.org/issues/2880#change-7775 22:07:28 <Terkhen> planetmaker: what do you think of http://dev.openttdcoop.org/issues/2991? 22:14:01 <planetmaker> hm, scales quite non-linearily with distance 22:14:38 <Terkhen> yes 22:15:01 <Terkhen> I used 2x because 1.1x or even 1.5x gave no noticeable result on short distances 22:15:22 <Terkhen> but then you get a lot of additional profit with long routes 22:15:23 <planetmaker> yes, I see that now with that numbers 22:15:43 <planetmaker> but on my typical maps 512^2 or so 500 tiles is looong :-) 22:16:00 <planetmaker> hm... query map size :-) 22:16:11 <planetmaker> largest dimension of map 22:16:27 <Terkhen> yes 22:16:33 <Terkhen> shouldn't be an issue IMO 22:16:49 <Terkhen> I haven't tested but a normal train is probably still better than the truck 22:16:55 <Terkhen> profit-wise 22:17:05 <planetmaker> that is ok 22:17:18 <Terkhen> so it gives you an edge over other vehicles, but nothing big 22:17:28 <planetmaker> that's IMHO the whole point 22:17:33 <Terkhen> on really long distances, if you care about profits you will be using trains instead 22:17:51 <planetmaker> they'll have refrigerator wagons, too. So... :-) 22:18:13 <Terkhen> :) 22:18:22 <Terkhen> I'll commit it once I finish with FMSP then 22:18:39 <Terkhen> it's difficult to fit such a big vehicle on a flatbed truck :P 22:18:44 <planetmaker> what, a scaling by map size? :-) 22:19:07 <Terkhen> hmm? 22:20:27 *** hanf has quit IRC 22:20:28 <planetmaker> I meant it as serious suggestion to use map_max_edge to scape the aging property :-) 22:20:34 <planetmaker> *scale 22:20:50 <planetmaker> as obviously with 100 tiles it has currently no effect 22:20:52 <Terkhen> but then it should affect all vehicles, not only refrigerated 22:21:24 <planetmaker> well, the reason for scaling this is to keep the efficiency advantage the same 22:21:32 <planetmaker> thus it should not affect all vehicles 22:22:00 <planetmaker> i.e. tune it that the refrigerator wagon gives ~20% advantage 22:22:13 <planetmaker> for the longest map side 22:22:18 <planetmaker> or maybe 30% 22:23:25 <Terkhen> it becomes worse with map size then, as you will usually keep your road routes of the same size 22:24:03 <planetmaker> that's some point, yes 22:24:09 <planetmaker> and trains? 22:24:20 <Terkhen> that's what you use for long distances, yes 22:24:37 <planetmaker> but the aging in truck and train should be both the same, or? 22:24:37 <Terkhen> but I don't think that we should scale them either 22:24:46 <planetmaker> hm. 22:25:02 <Terkhen> bigger maps are meant to take longer to traverse 22:25:03 <Terkhen> :P 22:25:03 <planetmaker> but then the property is either very strong or very weak. And only good at intermediate map sizes 22:25:11 <planetmaker> hu? 22:25:42 <Terkhen> if you choose to play in a bigger map, it is normal that you get more money on large routes 22:26:01 <Yexo> I wouldn't change the property depending on mapsize 22:26:06 <Yexo> that's a very confusing game-mechanic 22:26:25 <planetmaker> like "gives 10% gain" is easy 22:26:37 <planetmaker> of course "gives some gain" is also easy 22:27:02 * Yexo does small test on 64x64 map to see what profits are for a 40-tile route, now I use it in my own 256x256 game and the profits are differently for the same-sized 40-tile route? 22:27:21 <planetmaker> yes :-P Easy to understand ;-) 22:27:53 <planetmaker> ok, so without map scaling 22:29:01 <Terkhen> ok :) 22:42:46 <Brot6> Central European Train Set - Feature #3045: Wagons - sprites (Elukka) @ http://dev.openttdcoop.org/issues/3045#change-7777 22:44:59 <Brot6> OpenGFX+ Road Vehicles - Bug #3052 (New): Capacities for some cargos in the flatbed truck (Terkhen) @ http://dev.openttdcoop.org/issues/3052 22:47:52 <planetmaker> hm, Terkhen, wrt cargos: 22:48:14 <planetmaker> maybe consider that fmsp and ensp might weigh like 3t per unit? 22:48:42 <planetmaker> that's what I would according to the FIRS ticket see as sensible 22:48:48 <Terkhen> at least in the flatbed, the capacity is identical to goods 22:48:54 <Terkhen> that seems very wrong :) 22:48:57 <Terkhen> specially after seeing the sprites 22:48:58 <planetmaker> it'd automatically also reduce the capacity 22:48:59 <Terkhen> :P 22:49:12 <Terkhen> that makes sense, yes 22:49:13 <planetmaker> yes. But there's a callback for that. 22:49:21 <planetmaker> I'm not entirely sure how the CBs and this interact 22:49:36 <Terkhen> IIRC one of the capacity callbacks is weight dependent and the other is not 22:50:24 <Terkhen> but probably nml hides those ugly details for us :) 22:51:06 <Terkhen> according to nml docs, it is not dependent of weight 22:51:46 <planetmaker> yes, iirc nml hides that 22:53:35 <Brot6> OpenGFX+ Road Vehicles - Bug #3052: Capacities for some cargos in the flatbed truck (Terkhen) @ http://dev.openttdcoop.org/issues/3052#change-7779 23:00:33 *** Zuu has quit IRC 23:02:30 *** JVassie has quit IRC 23:03:10 <Terkhen> hmm... I have a strange bug and it is late 23:03:12 <Terkhen> good night :) 23:08:53 <planetmaker> good night Terkhen 23:22:32 <Brot6> Central European Train Set - Bug #3043: freight wagons (oberhuemer) @ http://dev.openttdcoop.org/issues/3043#change-7781 23:23:21 <Brot6> Central European Train Set - Bug #3043: freight wagons (oberhuemer) @ http://dev.openttdcoop.org/issues/3043#change-7781