Times are UTC Toggle Colours
00:00:38 <frosch123> likely without being more specific :p 00:01:32 <michi_cc> Reviving old stuff ;) I was just wondering which stuff I could kick from the map for the majority of tiles. 00:02:36 <frosch123> Ah :) 00:03:20 <planetmaker> hm :-) 00:03:23 <frosch123> Maybe related, maybe unrelated; but I have the plan to split the map array into a "persistent" part stored in savegames, and a "cache" part recomputed on load 00:03:46 <frosch123> like "slope", "nearest town" and such 00:03:57 <frosch123> "bridge over tile" 00:04:29 <planetmaker> computing too much upon load becomes problematically with network games 00:04:56 <frosch123> (the goal would be to provide more information consistently (like town for railtypes), speeding up stuff like slopes, while keeping a small savegame for connecting) 00:05:09 <frosch123> (while memory is no issue since 32bpp :p ) 00:05:22 <frosch123> planetmaker: haha, tell me you would notice 0.1 s? 00:05:23 <planetmaker> but more "order" in the info makes certainly sense 00:05:38 <planetmaker> not me. But max_join_time might :D 00:07:25 <planetmaker> and no, I don't exactly mind. But of course I notice people when they disconnect with this kind of error. It's very rare, though 00:07:35 <planetmaker> and then likely their connection most oftne 00:08:10 <frosch123> planetmaker: no recompution of caches would last long 00:08:23 <planetmaker> however I much like the idea. 00:08:24 <frosch123> it's only once :p 00:13:41 *** Zuu has quit IRC 01:00:59 *** FLHerne has quit IRC 01:10:27 <frosch123> hmm, timetable start time... 01:10:40 <frosch123> that's indeed not shared by shared orders 01:10:57 <frosch123> so, advanced setting for opening the vehicle window after cloning? :p 01:11:08 <frosch123> (similar to keep build tools active or quick goto?) 01:13:19 <planetmaker> hm. Not sure. But maybe yes 01:22:00 <frosch123> night 01:22:03 *** frosch123 has quit IRC 02:38:58 *** Supercheese has joined #openttd.dev 03:12:04 *** Supercheese has quit IRC 03:12:33 *** Supercheese has joined #openttd.dev 03:26:09 *** Supercheese has quit IRC 03:28:31 *** Supercheese has joined #openttd.dev 03:35:21 *** Supercheese has quit IRC 03:35:21 *** SmatZ has quit IRC 03:36:47 *** Supercheese has joined #openttd.dev 03:36:47 *** SmatZ has joined #openttd.dev 03:36:47 *** charm.oftc.net sets mode: +v SmatZ 07:44:05 *** Zuu has joined #openttd.dev 07:44:05 *** ChanServ sets mode: +v Zuu 08:23:41 *** Zuu has quit IRC 09:41:58 *** Supercheese has quit IRC 09:50:49 <peter1138> oh you were discussing road types 09:51:01 <peter1138> well, someone was 10:11:15 *** FLHerne has joined #openttd.dev 11:22:42 *** frosch123 has joined #openttd.dev 11:22:42 *** ChanServ sets mode: +v frosch123 11:37:48 <Terkhen> after a queue of poorly structured and hacky patches, I got a tar file with a height layer inside of it 11:38:12 <Terkhen> now to remake it in a nice way :) 11:38:42 <planetmaker> :-) 11:39:31 <frosch123> hola terkhen, moin pm :) 11:39:39 <Terkhen> hi :P 11:59:25 <frosch123> michi_cc: he, apparently pikka wrote a road spec some time ago :) 12:17:10 <michi_cc> Hmm, I'm not sure if a single road type per tile really is a good idea, considering the current situation with town-owned roads. 12:30:08 <Terkhen> gah, I forgot the "road layer" can of worms 12:30:42 <Terkhen> which gets even bigger when taking into account your current discussion :P 12:31:56 <Terkhen> https://secure.openttd.org/wiki/Terkhen/Scenario_format#Road_layer 12:33:04 <frosch123> Terkhen: i thought you just go for plain public roads 12:33:07 <Terkhen> the current solution removes the possibility of actually using the extended heightmap layers as "layers" in photoshop/gimp/whatever in exchange for having better human "readability" 12:33:11 <frosch123> while fancy roads are for companies only 12:33:35 <Terkhen> if all new roads are meant to only be company owned then I can ignore them completely :) 12:34:07 <Terkhen> with regard to the current solution, I wonder what is more important, layering or human readability 12:36:35 <planetmaker> is it a true colour image, where one channel is height, the other two encode other stuff? Or several binary layers? 12:37:09 <planetmaker> having separate binary images / layers will make it very easily extensible 12:38:11 <Terkhen> each layer is a different image 12:38:29 <Terkhen> and each one of them follows its own rules with regard to extra properties, palette and so on 12:39:05 <Terkhen> in principle they also must have exactly the same size, which is something that the current road layer breaks up for the sake of being able to actually see what it defines 12:39:11 <frosch123> Terkhen: i guess "ignoring" is the best thing to do currently :) 12:39:44 <planetmaker> Hm... that rule is broken in order to define road bits? 12:40:38 <Terkhen> frosch123: yes, that's what I was doing until now, but I thought about posting the current version of the format for discussion since it is what I'm going to implement when I finish the beautifying of the current code 12:40:55 <Terkhen> I could always mark it in the same way I did with industries: "complicated, it will be taken into account in the future" 12:41:38 <Terkhen> planetmaker: that rule is broken in order to define road bits in a human readable way, you could always use many colours to mark all the possible combinations of roadbits and oneway-ness 12:42:35 <Terkhen> that way you would keep the same size and you would be able to see where are the roads actually present, at the cost of just seeing a strange mixture of colours and having to deduce where they actually are 12:42:53 <Terkhen> another option is to just use a single 0-1 palette and have the game deduce the road bits from it 12:43:23 <Terkhen> but that gets strange with highways... should they be connected or not? :P 12:43:52 <Terkhen> Eddi suggested using some magic for that corner case, which probably means another colour 12:44:28 <planetmaker> hm. I'd also say: ignore it for now :D 12:44:44 <Terkhen> 0 -> no road; 1-> "connected to all adjacent tiles" road; 2-> "connected in X axis" road; 3 -> "connected in Y axis" road and so on 12:44:47 <Terkhen> ok :P 12:45:13 <Terkhen> I'll just add notes about the different possibilities at the format itself, so I don't forget about them :) 12:45:44 <planetmaker> that's a good choice imho 12:45:59 *** fonsinchen has joined #openttd.dev 12:45:59 *** ChanServ sets mode: +v fonsinchen 12:50:08 <Terkhen> hi fonsinchen 12:57:17 <fonsinchen> hi 13:46:46 *** FLHerne has quit IRC 13:59:07 *** FLHerne has joined #openttd.dev 14:15:27 <Belugas> hello 14:22:38 *** FLHerne has quit IRC 14:23:37 <V453000> frosch123: any luck with the random switches? :) 14:25:04 <frosch123> rb committed yesterday? 14:25:16 <V453000> o 14:25:34 <frosch123> r24882 14:25:37 <V453000> so my sane power random should not desync now? :) 14:29:39 <V453000> will test when it gets to binaries :) 14:46:29 *** FLHerne has joined #openttd.dev 15:52:15 *** ntoskrnl has joined #openttd.dev 17:11:30 *** Zuu has joined #openttd.dev 17:11:30 *** ChanServ sets mode: +v Zuu 17:13:11 *** FLHerne has quit IRC 17:52:41 <fonsinchen> http://www.tt-forums.net/viewtopic.php?f=33&t=63796&p=1059910#p1059910 17:52:55 <fonsinchen> Thanks for all the feedback, btw. 17:53:25 <fonsinchen> This issue about reservation needs to be decided upon, so I've put it up for discussion there. 18:12:27 *** fonsinchen has quit IRC 18:17:39 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24883 || 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:44:41 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24884 || 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:59:16 <Zuu> Regarding the Story Book; I'm thinking about leaving out questions+goal references for now and instead try to get the basic parts ready for 1.3. 18:59:16 <Zuu> As for questions, it is aimed at providing a chapter selection GUI. However, that is working fairly well in the current API except for aligning all text centered instead of to the left (but that could be fixed by extending the Question dialog). 18:59:38 <Zuu> Are these thoughts sound? 19:06:49 <frosch123> do you meaning leaving it out of the specs / concept, or leaving it out of the implementation? 19:08:58 *** Alberth has joined #openttd.dev 19:08:58 *** ChanServ sets mode: +v Alberth 19:27:07 <Zuu> leaving it out of implementation (for now) 19:47:05 *** Supercheese has joined #openttd.dev 19:49:56 <V453000> no desyncs yet \o/ Thanks 20:01:03 *** fonsinchen has joined #openttd.dev 20:01:03 *** ChanServ sets mode: +v fonsinchen 20:28:58 *** ntoskrnl has quit IRC 20:31:19 <Zuu> Hmm, after some thought, I'm unsure if the current StoryPage concept works without allowing a GS to add eg. a tile coordinate to generate a View button etc. The problem I see is that I do want the StoryBook to work without having events sent back to the GS. This however means that the GS cannot react on "next" or "previous" to change the view location. (which might be good to not confuse players) So instead I think the GS should embed a tile 20:31:19 <Zuu> reference into the page which would display a view/goto button. 20:32:15 <frosch123> why should prev/next scroll the viewport? 20:32:22 <frosch123> that's not something i would expect 20:32:26 <Zuu> For things like towns, industries etc. I'm thinking about a more generic concept of making {TOWN}, {INDUSTRY} etc. clickable. Though in that case you need to decide on a global concensus if the action should be to scrolll the viewport or open the corresponding window. 20:32:46 <Zuu> Unless the text on the previous page state that. 20:33:04 <Zuu> The current tutorial use that method. In the lack of anything better. 20:34:01 <frosch123> there could be a "goto location" button 20:34:09 <frosch123> but it should not scroll on "prev" / "next" 20:35:13 <Zuu> Is it sufficent with one location per page? - An alternative would be to turn each page into a list of chunks/elements. As elements you could then push texts as well as references to eg. tiles, towns, goals etc. 20:36:13 <frosch123> well, you can make it like the newspaper 20:36:22 <frosch123> they also have only one reference for ais 20:36:30 <frosch123> *gss 20:36:42 <frosch123> (though build-in subsidies have two) 20:36:42 <Zuu> I do however fear that resizing the window may become a performance issue if too many multi-line elements are stacked in the scrolled panel. 20:37:19 <Zuu> In debug builds on Windows, resizing is slow already with two elements. In the release build there is no such problem (on a i7 3.6 Ghz) 20:38:59 <Zuu> Having maximum one location reference may help to reduce length of pages, however if the task is to connect two towns, two locations would be interesting to allow. 20:42:57 <frosch123> same holds for goals :p 20:45:09 <Zuu> yes 20:46:21 <Zuu> Maybe allowing to compose pages of sections is the only way to go for enough flexibility. :-) 20:46:47 <frosch123> well, or you implement the text engine that allows clicking on text :p 20:46:51 <frosch123> like industry names 20:49:32 <Zuu> I think that would be neat to have, and probably not too hard depending on how early the symbols are evaluated. Ideally, it should either inject a view symbol before/after the town/industry name, make it underlined or make the cursor change when its hovered. 20:50:54 <frosch123> i would think it would be pretty hard :p 20:51:58 <frosch123> you need to mark the placed in the string in some way which allows it to survive the icu text compiler 20:52:11 <frosch123> currently only colour codes pass that, but they have no parameters 20:52:41 <frosch123> but maybe you can use other private use area characters to mark positions uniquely 20:54:01 <Alberth> setx or sety ? :p 20:54:18 <frosch123> we got rid of those 20:54:28 <frosch123> resp. we can get rid of them in the remaining places 20:56:32 <Rubidium> Alberth: setx/sety are trashed before passing it to ICU, mostly because it is NOT valid UTF8 20:56:35 <Zuu> I have no idea what the icu text compiler does. But one idea I got is to record at which position each parameter start/end. A version of DrawString would be created that doesn't draw anyting, but only return the id of the parameter at some coordinate. 20:57:04 <Zuu> position here refers to character position. 20:57:06 <frosch123> Zuu: it suffles character around and replaces some characters with other ones :p 20:57:35 <Zuu> Hmm 20:57:59 <frosch123> rtl and ligations 20:58:27 <Alberth> Zuu: position and size of character is not so trivial in the general sense, it may depend on characters around it 20:58:46 *** fonsinchen has quit IRC 20:58:48 <Zuu> So one would need to (ab)use two UTF8 symbols for parameter start/end which are then removed after icu. 20:59:17 <Alberth> space? (which gives you word count) 21:00:03 <Rubidium> some languages don't require spaces 21:00:15 <frosch123> Zuu: yes, something like "param 1 start", "param 1 end", "param 2 start", "param 3 end" 21:00:44 <frosch123> i think we are using proper uint32 characters, so there are some 100000 characters for private use 21:00:48 <Rubidium> oh gosh... that's nasty! 21:01:22 <Rubidium> {STATION} is a string, which is built from {TOWN} XYZ 21:01:41 <Alberth> ieks 21:01:42 <Rubidium> so, you'd get param 1 start param 1 start town name param 1 end XYZ param 1 end 21:01:57 <frosch123> :p 21:01:58 <Zuu> ReallyDoDrawString which draws the actual glyphs appear to iterate over each character/glyph to be drawn and increase x by each character with at a time. 21:02:23 <frosch123> Zuu: yes, but at that point the characters are no longer in the order they have been before 21:02:24 <Zuu> So being able to trace each character should be possible, if the parameter info can just be carried down there. :-) 21:02:33 <frosch123> and even their amount does not match 21:02:58 <Alberth> what's wrong with just character count? 21:03:09 <frosch123> ? 21:03:42 <frosch123> Rubidium: i guess you have to treat it like colour codes at top level 21:04:09 <frosch123> i.e. the original string has to contain "{clickref 1 start}{STATION}{clickref 1 end}" 21:04:39 <Rubidium> Alberth: http://www.icu-project.org/apiref/icu4c/ushape_8h.html#a1f89291c5a24a50b8f6dcad5eb4668f7 21:05:42 <Rubidium> and http://www.icu-project.org/apiref/icu4c/ubidi_8h.html#a26790ff71c59f223ded4047da5626725 21:06:50 <Alberth> hmm, and I thought standard letters were already difficult :p 21:07:20 <frosch123> it's not only arabic, ff fi fl ffi ffl might become single letters ff fi fl ffi ffl 21:08:43 <frosch123> hmm, oh, my irc client even did that translation :o 21:09:00 <frosch123> well, i typed the former symbols separate 21:09:13 <Zuu> Hmm, there are some "visual" functions in the ICU api that might be useful. 21:10:53 <Alberth> frosch123: I know, I also use (La)TeX :) 21:11:18 <Rubidium> yuck 21:14:23 <frosch123> i really did not expect it to replace ff while i am typing; i can delete the individual f again with backspace, i can also somewhat select them individually, but the selection is always drawn for both :p 21:18:42 <Alberth> I can walk over each letter with the first ones, but only over the words at the second ones 21:20:24 <frosch123> yeah, it is only some display thingie of my client 21:20:33 <frosch123> it likely actually send the letters i typed :) 21:20:52 <Alberth> that's a useful feature of a chat client :) 21:22:20 *** Alberth has left #openttd.dev 21:36:40 <michi_cc> Rubidium: I guess we don't have any language that uses glyphs outside the BMP. Looking at gfx.cpp:DrawString I see that we assign the output of Utf8Decode (UCS-4 AFAIK) to a UChar* string (which is UTF-16 according to ICU docs). 21:39:57 <Rubidium> I doubt any use that 21:39:58 *** fonsinchen has joined #openttd.dev 21:39:58 *** ChanServ sets mode: +v fonsinchen 21:41:20 <frosch123> if we only use bmp, then we only have 1000 private chars or so :p 21:43:08 <Rubidium> it's said to be E000-F8FF (6400) 21:43:59 <frosch123> so, only enough for about 3000 clickable parts per string 21:44:28 <frosch123> wasn't the string buffer 500 chars? 21:44:43 <Rubidium> but by the looks of the code we declare E0xx and E1xx as undrawable 21:45:12 <frosch123> isn't the train icon and such also in there? 21:45:54 <Rubidium> the string buffer is 2048 bytes 21:48:01 <Rubidium> train icon and such are in E2xx 21:48:44 <Rubidium> E0xx and E1xx are used for undrawn string codes ({G}, {STRINGn} etc) 21:48:45 <Zuu> 1) ICU operations seem to be limited to HandleBiDiAndArabicShapes. (with respect to DrawString) 21:48:45 <Zuu> 2) The two suffeling operations I can see are ubidi_writeReordered and u_shapeArabic. 21:48:45 <Zuu> 3) For ubidi_writeReordered there is ubidi_getLogicalIndex to transform a index in the string used for drawing to the string sent to DrawString. 21:48:45 <Zuu> 4) For u_shapeArabic, I think there is a parameter to do do the shaping in reverse. 21:48:45 <Zuu> 5) Finally, in the paint-loop of DrawString, when we figure out a word/character that matches the cursor x/y, we inject a control character into the string. The string is then run in reverse through u_shapeArabic. After this we read the new position of the control character and use ubidi_getLogicalIndex to reverse the operation of ubidi_writeReordered. Now we know the position in the char* string and only need to figure out if any parameter o 21:48:50 <Zuu> verlaps the character position. 21:50:57 <Zuu> But, if there are enough control characters to allocate one for each parameter, then it might be easier to inject them into the string pririor to ICU than trying to run ICU in reverse. 21:52:34 <Rubidium> there's still the nasty mess caused by SETX and cutting strings into lines 21:52:57 <frosch123> Rubidium: you can remove SETX 21:53:01 <frosch123> noone uses it anymore 21:54:16 <V453000> evening! 24884 seems to be working without any desync :) 21:54:45 <V453000> would it be possible to have more options for conditional orders? Like just simply more values - power, t.e., weight? 21:55:03 <V453000> weight would be awesome because it also means % loaded 21:55:38 <V453000> well I guess that is in the % itself .) 21:55:43 <Rubidium> that's going to wreak havoc with autoreplace and such 21:55:51 <V453000> but the other stats than speed would be great, what do you think? :) 21:56:24 <V453000> autoreplace is somehow linked with conditional orders in the code? :d 21:56:35 <V453000> oh you mean when you change vehicles, the values change 21:56:44 <V453000> well that already happens with speed 21:56:51 <V453000> people just update the orders afterwards 21:57:18 <Rubidium> didn't remember speed being in that list 21:57:24 <Rubidium> which moron added that? 21:58:10 <V453000> :d 21:58:49 <V453000> it works fine I guess 21:59:23 <V453000> I know some people even use that to separate trains with different speeds, but with shared orders 22:00:42 <V453000> imagine they could do the same with hills :> 22:04:37 <frosch123> i don't remember autoreplace doing anything with conditional orders 22:04:40 <frosch123> it only checks refit orders 22:05:38 <V453000> could we have power included in the conditionals pretty please? :)) 22:06:29 <frosch123> make a fs task, but please don't use this channel for individual requests 22:06:42 <V453000> oh, alright :) 22:09:01 <V453000> http://bugs.openttd.org/task/5432 :) 22:10:59 <Rubidium> frosch123: but you could easily answer his question ;) 22:11:07 <Rubidium> V453000: yes, it could be included 22:11:54 <V453000> thank you :) 22:22:07 *** fonsinchen has quit IRC 22:23:17 *** fonsinchen has joined #openttd.dev 22:23:17 *** ChanServ sets mode: +v fonsinchen 22:27:15 <michi_cc> Proper handling of non-BMP characters at the cost of an additional loop over all characters (the transformation back): http://www.icosahedron.de/openttd/patches/icu_utf16.diff 22:35:55 *** fonsinchen has quit IRC 22:40:46 <frosch123> what does that do? 22:42:19 <frosch123> ah, you remove usage of 16 bit uchars? 22:42:42 <michi_cc> Unbreak glyphs outside the BMP. The current code "converts" the UTF-32 we create in DrawString to UCS-2 for ICU (which trashes everything above BMP). The patch makes that a proper UTF-32->UTF-16->UTF-32 conversion. 22:44:31 <michi_cc> u_strFromUTF32 should be almost no extra cost as we do an initial loop in the old code as well. the convesion back (u_strToUTF32) is an extra string traversal. 22:45:50 <frosch123> u_strFromUTF32(input, lengthof(input), &length, (UChar32 *)buffer, -1, &err); <- shouldn't that lengthof rather be a sizeof? 22:46:05 <frosch123> (even though it is the same for uchar) 22:46:55 <frosch123> damn, confues u and w 22:47:09 <michi_cc> No, the ICU docs specifically state that all lengths are given in units and not bytes. 22:49:58 <frosch123> looks fine to me 23:04:35 <michi_cc> It still won't work though, as the we only use 16 bits to map glyph to SpriteID (even if all functions are taking WChar/uint32). 23:13:38 <michi_cc> Anyway, one breakage less to remember in the future ;) 23:13:45 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24885 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 23:56:53 *** Supercheese has quit IRC 23:57:23 *** Supercheese has joined #openttd.dev