Times are UTC Toggle Colours
00:29:45 *** Zuu has quit IRC 02:41:31 *** LordAro has quit IRC 07:29:55 *** Dewin has quit IRC 08:27:33 *** Zuu has joined #openttd.dev 08:27:33 *** ChanServ sets mode: +v Zuu 09:07:49 *** Alberth has joined #openttd.dev 09:07:49 *** ChanServ sets mode: +v Alberth 10:17:15 *** LordAro has joined #openttd.dev 10:17:15 *** ChanServ sets mode: +v LordAro 10:41:57 *** frosch123 has joined #openttd.dev 10:41:57 *** ChanServ sets mode: +v frosch123 11:02:15 *** ntoskrnl has joined #openttd.dev 11:02:53 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25117 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 11:18:32 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25118 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 11:41:29 *** LordAro has quit IRC 11:52:32 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25119 || 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:04:11 *** LordAro has joined #openttd.dev 12:04:11 *** ChanServ sets mode: +v LordAro 12:29:28 *** Supercheese has quit IRC 12:30:01 *** Supercheese has joined #openttd.dev 13:10:06 *** Ristovski has joined #openttd.dev 16:18:43 *** fonsinchen has joined #openttd.dev 16:18:43 *** ChanServ sets mode: +v fonsinchen 16:40:40 <Zuu> I wonder, assuming that the story book is wanted, which path to choose. The problem at hand is that the story book will want to refer to industries towns etc. and have currently no way to allow user to click on some button to go there. 16:41:25 <Zuu> I think there is two ways to solve this. A) using click-on-text or B) to use stacked content. Eg. first some text, then a reference to a town and then some more text. 16:42:21 <frosch123> C) Text at the top, a list of locations (names) at the bottom 16:42:46 <Zuu> I have put some work into A) and have a working patch for encoding click areas into a char** string. However taking that into working with strings from GSes is some aditional work and more code that will need to be maintained. 16:45:23 <Zuu> I also had some plans for displaying answer options at the bottom or goals. Perhaps one could streamline it down to only allowing location references (and reference to goals) or answers on the same page. 16:45:29 <frosch123> subsidies have only two locations, but they solve it by scrolling to the 1st location, and if the viewport is already there, scroll to the 2nd 16:46:05 <frosch123> do you have a list of example use cases? 16:46:11 <frosch123> for me the discussion is quite abstract 16:46:22 <frosch123> i do not have any vision on how to use the feature 16:47:17 <Zuu> I think that the Story Book would be used by Beginner Tutorial, but also scenarios or GSes that need to tell a story or give some more text than a short sentence in the goal list. 16:48:45 <Zuu> In Beginner Tutorial I move the viewport for users (after they click on continue), this could be removed if the location is a button that can be clicked. Also having the location coded into the window and not an asynchronos response from the GS will give a more responsive UI. 16:49:08 <frosch123> do you have a usecase where you would need more than 2 locations for an item? 16:49:44 <Zuu> Transport X from any of industry A, B or C to D 16:50:01 <Zuu> Although that would be a goal then. 16:51:42 <frosch123> http://paste.openttdcoop.org/show/2174/ <- that would be how C would look like 16:52:17 <Zuu> Yes 16:52:25 <frosch123> So, maybe one can limit it to two locations per "item" on a page 16:52:35 <frosch123> the two locations would toggle like for subsidies 16:52:43 <frosch123> if you have more locations you would have to use more items 16:52:46 <Zuu> If a location is assumed to never span more than one line, the resizing code can be made quite quick which is otherwise a drawback with B) 16:53:07 <Zuu> (window resize) 16:53:40 <frosch123> i think multiple items per page sounds best up to now 16:53:53 <frosch123> you just need some method to sort them :p 16:54:06 <Zuu> Why allow more than one location per item, if you say that each line in your example is an item? 16:54:37 <Zuu> Eg. if you need more locations, just add an additional item. 16:56:30 <Zuu> Also, if the items are "location" and not "industry", "town", etc. that will keep the API slim and leave it up to a GS (library) to turn towns etc. into a tile index. Which in turn give them more freedom what to pass as location. 16:57:32 <frosch123> "Transport stuff from A to B" looks weird as two lines 16:59:03 <Zuu> The text above would say that, and the location list would then contain A and B. 16:59:33 <frosch123> ok, also an option :) 16:59:35 <Zuu> Eg. like the reference list of an article. 17:00:44 *** Lord_Aro has joined #openttd.dev 17:01:34 *** LordAro is now known as Guest77 17:01:34 *** Lord_Aro is now known as LordAro 17:01:52 <Zuu> Or an Item can either be a Location or a reference to a Goal. In the later case it could show the literal goal text. Not sure if clicking on it will open the goal window or going to the goal location. 17:06:40 *** Guest77 has quit IRC 17:27:22 *** Lord_Aro has joined #openttd.dev 17:33:50 *** LordAro has quit IRC 17:34:01 *** Lord_Aro is now known as LordAro 18:27:07 *** Lord_Aro has joined #openttd.dev 18:33:00 *** LordAro has quit IRC 18:33:16 *** Ristovski has quit IRC 18:43:03 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25120 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 18:52:01 *** Dewin has joined #openttd.dev 19:13:22 *** Lord_Aro is now known as LordAro 19:13:32 <Zuu> Comparison of alternative B and C: https://secure.openttd.org/wiki/File:Alternative-b-and-c.png 19:14:47 <frosch123> with B it's up to the gs to decide whether it wants C, right? 19:14:53 <Zuu> Yes 19:15:46 <frosch123> that should be better, shouldn't it? :p 19:15:48 <Zuu> B is a bit more expansive in computation as it allows multiple multi-line text elements. Those cause resizing the window slow down OpenTTD debug build on my i7. The non-debug build works fine. 19:16:31 <Zuu> I like that B generalize text as a content item. 19:16:47 <frosch123> i don't get why B should be slower than C 19:16:59 <frosch123> it displays the same, just in different order 19:17:15 <Zuu> C only have two multi-line text elements (the title and the body text) 19:17:21 <Zuu> B could have 10 such items. 19:17:37 <frosch123> well, but you only need to recompute the height when the width changes 19:17:42 <frosch123> not when drawing and such 19:17:53 <Zuu> When the window is resized OpenTTD have to test-render all multi-line texts to compute the number of lines needed. 19:18:03 <Zuu> Correct 19:18:13 <frosch123> anyway, B looks better :) 19:18:48 <Zuu> I hope that release builds will not slow down when resizing a long page even on slower machines than 3,6 GHz i7. :-) 19:19:53 <Zuu> Or we will have to set a limit on X number of text items on a page. 19:20:38 <Alberth> several other windows just render the content, and keep track of the bottom. If it is below the window bottom, resize the window 19:21:58 <Zuu> This window uses a scrollbar. Does your method work with that? 19:22:52 <Zuu> Anyway, I will code B and hope that it is not too slow. 19:24:14 <Alberth> those windows do not have a scrollbar 19:28:22 <frosch123> Zuu: the console also does multiline stuff with scrolling 19:37:35 <frosch123> http://paste.openttdcoop.org/show/2175/ <- ai gui crashes when resizing it too small 19:38:19 <frosch123> i only noticed because my ottd was still switched to german after the gs text tests from yesterday 19:38:37 <frosch123> in english the button texts are shorter, so the editbox never is resized to 0 :p 19:39:11 <Zuu> Hmm, so this is a generic fix in src/widget.cpp. Good 19:40:07 <Zuu> I got random crashes with my patch until I figured out that not setting a drawing parameter in the callback for widget drawing parameter was the reason for them. 19:40:16 <frosch123> yeah, whenever you are able to make a window so small that a editbox becomes zero width 19:40:20 <Zuu> This only happened if there are zero pages. 19:41:38 <Zuu> For the drop down widget the drop down image appears to be hardcoded as 14 px wide. If not the game could possible crash if the image can grow large enough to not fit a narrow drop down widget. 19:49:48 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25121 || 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:57:11 *** Ristovski has joined #openttd.dev 20:21:47 <Rubidium> ugh... the Tamil language rendering bug seems to be quite major 20:22:07 <frosch123> the flickering? 20:22:11 <Rubidium> for some reason they seem to render some characters over eachother, or at least at different offsets 20:22:44 <frosch123> yeah, it looked quite fancy 20:22:50 <Rubidium> (which we obviously do not do) 20:23:09 <Rubidium> http://userguide.icu-project.org/layoutengine is roughly what we need 20:23:49 <Rubidium> which layouts characters and tells you at which offsets you need to draw what glyph, or something like that 20:25:02 <Rubidium> the nuisance is that it makes splitting lines and the likes harder as well 20:25:31 <Rubidium> as we do not necessarily know where the glyphs are drawn 20:28:09 <Rubidium> on the other hand, it will give some mapping to the location where which glyph is going to be drawn which might be of interest for Zuu 20:28:26 <Rubidium> or at least this whole thing is going to mess up Zuu's work 20:31:10 <Zuu> Rubidium: For the moment I've dropped it in favor for another solution for the Story Book window. (see earlier discussions in this channel today) 20:32:08 <Zuu> Basically, I don't know if it is worth all work and then the time it takes to maintain click-on-text. Instead I examinate an alternative solution which might end up be equally good and easier to discover for users. 20:42:00 *** Alberth has left #openttd.dev 20:51:19 <michi_cc> frosch123: Told you we need a text rendering engine :) 20:51:47 <frosch123> :) 20:55:07 <michi_cc> Rubidium: http://www.icu-project.org/apiref/icu4c/classicu_1_1ParagraphLayout.html 20:58:03 <michi_cc> Needs more of the icu data though for UBreakIterator which at least in source filesystem size is another 3MB. 20:58:52 <michi_cc> There's also the HarfBuzz layout engine, but somebody seems to have forgotten the documentation... 20:59:16 *** LordAro has quit IRC 21:01:53 <Rubidium> looks interesting and might even remove some OpenTTD code 21:02:32 <Rubidium> and the question is whether the 3 MB is really noticable; the biggest problem is getting new libicu builds for Windows 21:03:39 <michi_cc> Is it? I built 5.1.1 a few hours ago and it worked right out of the box. 21:03:54 <frosch123> that class only needs 3.2 21:04:04 <frosch123> which one is the farm using? 21:04:19 <Rubidium> the farm is using the one from openttd_useful 21:04:21 <michi_cc> Okay, DLL version, didn't try the static lib yet. 21:04:25 <michi_cc> So 4.4 I think. 21:04:35 <frosch123> 4.4 is newer than 3.2 :p 21:04:51 *** fonsinchen has quit IRC 21:04:53 <Rubidium> which... for all intends and purposes is built with MSVC 2005 support 21:04:56 <michi_cc> No lib for the layout engine in the zip though. 21:05:06 <frosch123> oh, it's separate? 21:05:39 <michi_cc> Rubidium: I used 2010 for 5.1.1 as the project files are for that, didn't try with 2008. 21:05:55 <Rubidium> and the ones newer than the one used in openttd_useful are not building with 2005 anymore 21:06:43 <Rubidium> one *could* just drop 2005 and 2008 support, but then I'd say that the whole openttd_useful should be rebuild/updated to 2010 21:07:12 <frosch123> that means dropping directmusic and such, right? 21:07:25 <michi_cc> Compile farm is 2010 and I suspect the resulting static lib would also work with the 2008 libc. Not sure we really need to supply libs for 2005. 21:07:39 <michi_cc> frosch123: No. 21:09:59 <Rubidium> I do not know what the 2008 / 2010 library format differences are 21:10:19 <Rubidium> but 2005 doesn't like 2008, so I'd expect 2008 not liking 2010 either 21:13:18 <Rubidium> in any case, almost all the libraries are outdated too much for it to be funny 21:16:17 *** ntoskrnl has quit IRC 21:20:16 <Rubidium> anyhow... I do not have 2005 or 2008 anymore 21:21:24 <Rubidium> so I can't test whether it works, but if we can't deliver a openttd_useful for a particular (MSVC) compiler we shouldn't mark that version as supported anymore 21:22:07 <frosch123> i have an old copy of the windows farm, with 2008 21:22:20 <Rubidium> IMHO dropping 2005 and 2008 might not be such a big deal, especially if that means we could use more C++11 features 21:22:50 <frosch123> isn't using c++11 on linux a no-go? 21:23:04 <Rubidium> no idea 21:23:07 <frosch123> resp. on every system using shared libraries 21:23:43 <frosch123> the stl changes, and if some shared library uses std::vector<uint> 21:24:01 <frosch123> it will crash if the lib is compiled with c++11 and some other one is not 21:24:16 <Rubidium> hmm, that'd be a pity 21:25:57 <michi_cc> Rubidium: MSVC 2008 had no problems compiling OTTD with a static freetype made with 2010. freetype is C only though, so it would still be possible that a 2010 lib could have some conflicts with C++ library functions. 21:26:20 <Rubidium> I only tried ICU I think 21:26:45 <michi_cc> Well, the layout engine part of ICU is C++ ... 21:29:06 <michi_cc> We could possibly offer both the current useful zip (and maybe try to get/compile the ICU layout part as well) and an updated zip for 2010. 21:29:55 <Rubidium> then we need someone with MSVC 2005 to compile the old version of ICU 21:32:35 <michi_cc> "Acquiring" it isn't really a problem and a VM should do I hope. 21:32:45 <frosch123> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49561#c16 <- oh, apparently gcc decided to not strictly implement c++11 in favour of keeping api compatibility 21:36:54 <Rubidium> I then wonder when they're going to do that ABI change 21:38:22 <frosch123> well, apparently we can blame it on the distros 21:38:45 <frosch123> and if we make sure that the generic binary links all c++ libs statically, and only pure c ones dynamically 21:38:50 <frosch123> we should be safe 21:57:01 *** Ristovski has quit IRC 22:54:28 *** Zuu has quit IRC 22:56:17 *** frosch123 has quit IRC