Log for on 8th December 2012:
Times are UTC Toggle Colours
00:16:01  *** FLHerne has quit IRC
01:57:19  *** frosch123 has quit IRC
09:01:50  *** Alberth has joined
09:01:50  *** ChanServ sets mode: +v Alberth
10:11:11  *** Supercheese has quit IRC
10:13:53  <Terkhen> <--- just in case anyone wonders how the following discussion starts
10:14:02  <Terkhen> Alberth: yes, my idea is to always use the new scenario format
10:14:21  <Terkhen> even for a terrain only heightmap, you may want to define a preferred climate or a scenario name
10:15:21  <Alberth> perhaps first just save everything?
10:15:59  <Alberth> adding an 'if' to leave out some stuff is easy enough :p
10:16:22  <Terkhen> hmm, true
10:16:31  <Terkhen> that would be simpler :P
10:17:41  <Terkhen> so maybe the next step should just be "create a extended heightmap when saving as heightmap"
10:20:50  * Alberth ponders how to explain to users about extracting tar files
10:21:37  <Terkhen> for windows, install 7z or winrar and right click on the tar and select extract
10:22:47  <Alberth> off-topic, but doesn't it look pretty?
10:24:18  <Terkhen> indeed :)
10:24:49  <Terkhen> it looks a lot more advanced than the last time I checked it
10:25:11  <Terkhen> the blog post arrived to my rss reader right now :P
10:27:38  <Alberth> It's amazing how much a few platform and support sprites can do in an image :)
10:29:46  <Terkhen> :)
10:30:39  <Terkhen> I'm also wondering if it is worth the effort to include code to support a "format_version" to the scenario format
10:31:27  <Terkhen> my initial plan is to just append "format_version=1" to the metadata files, just in case that future changes require changing the format and including code to support multiple format versions
10:32:11  <Alberth> sounds like a good plan
10:32:23  <Terkhen> but to not create a saveload-ish framework for now, because we could never use it :P
10:32:29  <Terkhen> ok :)
10:32:52  <Alberth> euhm, is that a version for the entire scenario format, or a per-layer version?
10:33:04  <Terkhen> entire format
10:33:42  <Alberth> ok
10:33:57  <Alberth> the saveload framework will come in time :)
10:35:03  <Terkhen> as soon as something breaks one of the existing parameters of the metadata file, one of the layers or one of the object files... since most stuff is optional, the addition of parameters or even new layers or object files does not need a format bump
10:59:23  *** frosch123 has joined
10:59:23  *** ChanServ sets mode: +v frosch123
11:06:53  <Alberth> moin
11:10:50  <Terkhen> hi frosch123
11:17:43  *** ntoskrnl has joined
11:18:39  <frosch123> moin :)
11:36:51  <Terkhen> I'm giving a look at how OpenTTD currently creates png files... I don't know if it would be worth the effort to check how to create png "files" in memory only to pass them directly to the tar writing functions, or if writing temporary png files and deleting them later would not be too hackish
11:42:46  *** DorpsGek sets mode: +v ntoskrnl
11:44:13  <Terkhen> ntoskrnl: I checked Alberth's code for writing tar files and stream based seems possible
11:44:37  <Terkhen> so yes, that would be a better option than just writing the whole file at once
11:44:51  <Alberth> it was designed to allow that :)
11:45:03  <Terkhen> I misunderstood WriteFileData :P
11:46:04  <Terkhen> given that this looks like the right way to do it, I'm going to check libpng functions to see if it is possible to do this instead of how things are done currently at screenshot.cpp
11:47:17  <Terkhen> of course, this change would require to modify screenshot.cpp functions to allow for this, which probably implies another big queue :P
11:47:49  <Alberth> why, screenshots end up on disk anyway
11:49:15  <Terkhen> the functions that write pngs are currently on screenshot.cpp, and they assume that you want to write the png to a file
11:49:59  <Terkhen> I would need to either duplicate the png write functionality or to abstract it nicely, probably creating a new function in another file that is used both by screenshot.cpp and extended heightmaps
11:55:40  <Alberth> good point
13:27:05  <michi_cc> Terkhen: In case you are still checking, you want look up png_set_write_fn.
14:13:54  <Terkhen> michi_cc: thanks for telling me, lets see :)
14:56:02  *** ntoskrnl has quit IRC
17:00:11  <frosch123>  <- more clever SetDParam for numbers in UpdateWidgetSize
17:00:25  <frosch123> <- do not display disabled news when clicking "previous news"
17:03:29  <Alberth> 20 looks fine
17:04:04  * frosch123 fixed some doxygen issues with 20
17:06:15  <Alberth> prev_news  sounds a bit weird,  news_entry  or display_news instead?
17:06:35  <frosch123> "ni" is used often for unspecific newsitems
17:07:25  <Terkhen> static const uint biggest_digit = 8; ///< Digit with the biggest string width. <--- in 20, is that true for all fonts?
17:07:27  <Alberth> fine too
17:07:45  <frosch123> Terkhen: that might be the next feature, but i did not feel like that :p
17:08:34  <Terkhen> ok, it's an improvement over the current situation anyways :)
17:10:14  <Terkhen> both patches look fine to me
17:10:39  <Terkhen> specially because they don't introduce 36 strings to be translated :P
17:14:02  <frosch123> :p
17:18:00  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24800 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
17:18:22  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24801 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
17:18:39  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24802 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
18:44:57  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24803 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
18:53:48  *** Alberth has left
20:45:16  *** FLHerne has joined
22:53:41  *** Supercheese has joined

Powered by YARRSTE version: svn-trunk