Log for #openttdcoop.devzone on 8th September 2011:
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) @
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) @
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) @
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) @
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) @
09:08:19  <Brot6> OpenGFX+ Landscape - Feature Request #3049 (New): Ignore Alpine when climate is subtropical (Terkhen) @
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) @
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) @
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> <-- like that
12:17:20  <Webster> Title: Imagebin - A place to slap up your images. (at
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) @
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 "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> 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) @
14:55:38  <Brot6> Central European Train Set - Feature #3045: Wagons - sprites (oberhuemer) @
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) @
14:56:56  <Ammler> no license file, no mention of a license = GPL
14:57:14  <Ammler> according to
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) @
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) @
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) @
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) @
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 -
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:
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 -
17:26:33  <planetmaker> <--
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) @
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) -
17:29:21  <Brot6> vactrainset: compile of r1 still failed (#3044) -
17:29:56  * LordAro is scared of nfo
17:30:27  <planetmaker> LordAro: You could write in in NML alternatively
17:30:53  <planetmaker>
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
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 and ?
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 :) - 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>
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: 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
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: 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>
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:
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 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 (
19:06:08  <Brot6> clientpatches: compile of r22908 still failed (#2964) -
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 -
19:13:25  <Brot6> serverpatches: compile of r22908 still failed (#2966) -
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) -
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>
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) @
20:59:54  <andythenorth> good night
21:01:28  <Brot6> OpenGFX+ Airports - Feature #3051 (New): Reuse (part of) Combined Airport Set V0.5 (yexo) @
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) @
21:09:43  <Brot6> OpenGFX+ Airports - Feature #3051: Reuse (part of) Combined Airport Set V0.5 (planetmaker) @
21:12:36  <Brot6> OpenGFX+ Airports - Feature #3051: Reuse (part of) Combined Airport Set V0.5 (yexo) @
21:14:38  <Brot6> OpenGFX+ Airports - Feature #3051: Reuse (part of) Combined Airport Set V0.5 (planetmaker) @
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) @
22:07:28  <Terkhen> planetmaker: what do you think of
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) @
22:44:59  <Brot6> OpenGFX+ Road Vehicles - Bug #3052 (New): Capacities for some cargos in the flatbed truck (Terkhen) @
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) @
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) @
23:23:21  <Brot6> Central European Train Set - Bug #3043: freight wagons (oberhuemer) @

Powered by YARRSTE version: svn-trunk