Config
Log for #openttd.dev on 7th May 2013:
Times are UTC Toggle Colours
06:47:09  *** Zuu has joined #openttd.dev
06:47:09  *** ChanServ sets mode: +v Zuu
07:17:15  *** Zuu has quit IRC
07:52:08  *** Supercheese has quit IRC
10:05:45  *** Ristovski has joined #openttd.dev
10:38:56  *** frosch123 has joined #openttd.dev
10:38:56  *** ChanServ sets mode: +v frosch123
10:47:10  <frosch123> planetmaker: for ottd you could make the spritenumber of the first coast sprite avaialble via actiond
10:47:15  <frosch123> similiar to the 2cc remaps
10:47:29  <frosch123> (will only work in ottd though, not possible for ttdp, if you care :p )
10:52:16  <frosch123> http://paste.openttdcoop.org/show/2268/ <- basically that
10:53:27  <planetmaker> frosch123, but how does that work with base sets? They have the sprites in the base grf and 10 in the extra grf?
10:53:38  <frosch123> nope
10:53:45  <frosch123> you are underestimating the magic that ottd does :p
10:53:57  <planetmaker> likely :-)
10:54:11  <planetmaker> frosch123, can we make that approach you pasted more generic? So that it takes a parameter
10:54:17  <frosch123> for ottd the shores and foundations are always in the same spot (though they are moved when you add new gui sprites)=
10:54:18  <planetmaker> which indicates the action5 set
10:54:25  <planetmaker> or which allows adding further?
10:54:36  <frosch123> it does not make a lot of sense for other action5 sets
10:54:46  <planetmaker> tram sprites
10:54:47  <frosch123> i just took those which make sense, and would rather hide others
10:54:49  <planetmaker> etc
10:55:01  <frosch123> planetmaker: so we can never change tram sprites again?
10:55:07  <frosch123> good luck with road types :p
10:55:11  <planetmaker> yes, no need to expose all. But so that we don't add a separate var for each?
10:55:19  <frosch123> i already wonder about exposing the foundatin graphhics
10:55:51  <frosch123> if we would include slope information in tile layouts, ottd could draw the proper foundations itself
10:56:10  <frosch123> planetmaker: we already have a var for 2cc, and i don't see we would get mroe
10:56:25  <frosch123> and there is currently no method for a parameterised action d variable
10:56:56  <planetmaker> well, yes. The terrain sprites are needed as reference often
10:57:05  <planetmaker> so that's most important
10:57:17  <planetmaker> foundations... dunno... I really haven#t thought about them
10:58:03  <frosch123> http://wiki.openttd.org/Frosch/New_Results#CB_30.2F14E.2F150:_Decide_drawing_foundations <- well, i thought about industries, objects, and houses
10:58:37  <frosch123> foundations are quite complicated to use for newgrf
10:58:45  <frosch123> because the Z position varies in layouts
10:59:02  <frosch123> so, maybe we should skip them, and only expose the shore base then? :)
10:59:35  <frosch123> i don't see anyone using the foundations sprites, except in a fixed slope configuration
10:59:42  <frosch123> but well, maybe that is reason enough
11:00:40  <planetmaker> well, One might want to use them in terraced multi-tile house or industry :-)
11:01:13  <frosch123> well, using the default foundations might be better than drawing custom ones :p
11:01:35  <planetmaker> default foundations or default foundation sprites? :-)
11:03:27  <planetmaker> interesting... I don't recall reading the wiki page you linked :-)
11:03:54  <planetmaker> I might have, but probably forgot :-)
11:05:02  <planetmaker> And if we use separate variables like you suggest, we can of course always add foundations sprite offset later in another var
11:05:28  <planetmaker> having the shore sprite offset for now would suffice for me. And likely to the guy in that thread, too
11:06:46  <frosch123> well, in other cases we added the magic to the tile layout drawing
11:07:08  <frosch123> i.e. if you use the plain water tile in a sprite layout, ottd will add canal/river borders to it
11:07:22  <frosch123> we just never had a good idea how to do that with shores
11:07:44  <frosch123> esp. because the shore detection is so complicated, when the shore is inside the industry .p
11:07:46  <planetmaker> hu?
11:08:21  <frosch123> what hu?
11:08:53  <planetmaker> you mean... if I take an industry. How do I make it a water tile?
11:09:00  <planetmaker> or you mean to leave a gap in the layout?
11:09:06  <planetmaker> *tile layout
11:09:12  <frosch123> no, a industry you build on water
11:09:18  <frosch123> like firs harbour
11:09:20  <frosch123> or oilrig
11:09:23  <frosch123> fishing grounds
11:09:32  <planetmaker> yeah. but they have no river banks?
11:09:40  <frosch123> the newgrf draws the plain water sprite
11:09:50  <frosch123> ottd catches that case and turns it into drawing the river or canal water
11:09:52  <planetmaker> that's a plain flat terrain tile
11:09:54  <frosch123> instead of the sea water
11:09:57  <frosch123> including the borders
11:10:23  <planetmaker> sorry... I miss something. How does an industry draw a plain water tile?
11:10:37  <planetmaker> I can reference the sprite just fine. but that doesn#t make it water
11:10:42  <frosch123> it just puts the default ttd sprite number in the ground sprite
11:11:01  <planetmaker> but... no borders are drawn then?
11:11:16  <frosch123> ottd catches that case and does something different
11:11:48  <planetmaker> uh... then ogfx-landscape wind mills on water should have river / canal borders
11:11:57  <frosch123> see IndustryDrawTileLayout
11:12:00  <planetmaker> or is an additional requirement that there's no child sprite or building?
11:12:11  <frosch123> it must be the first ground sprite
11:12:15  <frosch123> not some additional ground sprite
11:13:23  <planetmaker> uh... that's weired magic in that place
11:13:31  <planetmaker> and tbh I've never seen it kick in
11:13:42  <frosch123> it works for default industries
11:13:45  <frosch123> at least it used to work :p
11:14:33  <planetmaker> ah... so I'll only see a difference, if is a river or canal water tile
11:14:40  <planetmaker>  as sea tiles have no border. hm...
11:14:51  <frosch123> well, obviously :p
11:15:00  <planetmaker> I guess I never saw that case. Need to check
11:15:29  <planetmaker> But why do we do so only for flat tiles?
11:15:33  <planetmaker> why not for sloped?
11:15:40  <frosch123> tell me how to do it for slopes :p
11:15:42  <planetmaker> like for coasts?
11:15:48  <frosch123> which sprites?
11:15:55  <frosch123> what is coast, what is land?
11:16:09  <frosch123> you do not know what the industry does on the inside
11:16:23  <frosch123> you would have to check whether a neighboured tile would draw a water ground or somiething like that
11:16:44  <frosch123> or you could require the industry to draw the default coast graphics
11:16:50  <frosch123> which you could replace with other ones
11:16:59  <frosch123> but then there are no sprites for the diagonal coasts
11:18:24  <planetmaker> well :-) I generally believe that the best approach to all this would be: always draw the ground as if nothing was on it. Then draw anything on top which the industry / object / house / whatever wants to draw on top
11:18:35  <planetmaker> it then can draw water where there's land or vice versa
11:21:50  <planetmaker> hm... can industries set the water class of a tile? I think not
11:26:34  <frosch123> no, it's whatever it was before
11:26:52  <frosch123> though autoslope might completely break it :p
11:27:16  <frosch123> so, when the industry is removed, it checks whether the waterclass is still possible on the slope/height :p
11:27:31  <planetmaker> :-)
11:27:56  <planetmaker> But generally wouldn't it make sense to draw the world without any objects / houses / industries /... and then those on top?
11:28:08  <planetmaker> It avoids the need for lookup (though they still could)?
11:28:22  <frosch123> well, yeah, it would also fix snow and desert density :p
11:28:30  <planetmaker> yes
11:28:45  <frosch123> but i guess we would need to mess around with the map array for that
11:28:56  <frosch123> and separate the surface stuff from the rest
11:28:59  <planetmaker> snow can be externalized. I think it should
11:29:22  <frosch123> what do you mean with 'externalized' ?
11:29:24  <planetmaker> then we only need two zones or three: desert, grass, rainforest
11:29:29  <planetmaker> by snowline height
11:29:33  <planetmaker> not in map array
11:29:40  <frosch123> ah, that way, yes
11:29:54  <frosch123> i did that once, but never made it work properly :p
11:30:12  <planetmaker> sm4tz or m1chi did so, too, afair
11:30:47  <frosch123> i only did the snow line height thingie
11:31:01  <planetmaker> yes, that's what I mean they did, too :-)
11:31:14  <planetmaker> but... my memory is not know for accurate remembrance ;-)
11:31:18  <planetmaker> *known
11:33:09  <planetmaker> how many bits do we need for landscape description? 8 for height, 2 or 3 for terrain type. 2 or 3 for water class
11:37:49  <planetmaker> 2 water type bits.
11:38:14  <planetmaker> 2 bits tropcial zone
11:38:21  <planetmaker> thus 4 bits for tile description
11:38:31  <planetmaker> density is in some. but in principle can be derived
11:39:04  <planetmaker> both for snow and desert transition. bare ground density is only needed for normal ground tiles, no others
11:42:20  <frosch123> i think that's about what i thought in 2008 or 2009 when i first had the idea to expose shores/foundations via action d :p
11:42:34  <planetmaker> :-)
11:44:32  <planetmaker> so... should we make a new attempt at changing it? :-)
11:44:59  <frosch123> not me, not now :p
11:45:09  <planetmaker> :-)
11:45:57  <planetmaker> but... half of http://paste.openttdcoop.org/show/2268/ would bring us further quite a step in some landscape issues :-)
11:46:58  <frosch123> well, it's certainly better than people hardcoding sprite numbers
11:47:07  <frosch123> and then complaining that it breaks when we add a gui sprite :p
11:47:19  <planetmaker> yes. And it indeed solves an issue which I tried to programme around in NewGRFs for some time
11:48:01  <planetmaker> definitely
11:48:10  <frosch123> so, add them anyway? :p
11:49:23  <planetmaker> them? We'd be well off with just the shore base sprite.
11:49:31  <planetmaker> Or did I miss that we have any alternative?
11:49:49  <planetmaker> it would not be a loss even when the ground issue is totally reworked to be always drawn
11:50:41  <planetmaker> I took from the discussion that foundation offset needs maybe another thought, so I'd not add that for now
11:51:51  <frosch123> i think foundations hurt even less
11:52:33  <planetmaker> but shore base doesn't hurt either? Or how can it hurt?
11:52:45  <planetmaker> did I miss that?
12:04:24  <planetmaker> If you don't want to go for it I'll think about your paste tonight, I guess :D
12:35:59  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25230 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
12:45:44  <frosch123> planetmaker: i assign the nml task to you :p
13:00:28  <planetmaker> thanks. done :-)
13:46:34  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25231 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
15:10:52  *** Zuu has joined #openttd.dev
15:10:52  *** ChanServ sets mode: +v Zuu
16:31:04  *** Ristovski has quit IRC
17:35:26  *** Alberth has joined #openttd.dev
17:35:27  *** ChanServ sets mode: +v Alberth
17:42:29  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25232 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
19:09:49  *** Supercheese has joined #openttd.dev
20:15:29  *** Zuu has quit IRC
20:18:24  *** Zuu has joined #openttd.dev
20:18:24  *** ChanServ sets mode: +v Zuu
20:25:21  *** Supercheese has quit IRC
21:04:48  *** frosch123 has quit IRC
21:08:31  *** Alberth has left #openttd.dev
23:10:46  *** Zuu has quit IRC

Powered by YARRSTE version: svn-trunk