Log for on 3rd January 2013:
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
03:12:04  *** Supercheese has quit IRC
03:12:33  *** Supercheese has joined
03:26:09  *** Supercheese has quit IRC
03:28:31  *** Supercheese has joined
03:35:21  *** Supercheese has quit IRC
03:35:21  *** SmatZ has quit IRC
03:36:47  *** Supercheese has joined
03:36:47  *** SmatZ has joined
03:36:47  *** sets mode: +v SmatZ
07:44:05  *** Zuu has joined
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
11:22:42  *** frosch123 has joined
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>
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
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
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
15:52:15  *** ntoskrnl has joined
17:11:30  *** Zuu has joined
17:11:30  *** ChanServ sets mode: +v Zuu
17:13:11  *** FLHerne has quit IRC
17:52:41  <fonsinchen>
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: || 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: || 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
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
19:49:56  <V453000> no desyncs yet \o/ Thanks
20:01:03  *** fonsinchen has joined
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:
21:05:42  <Rubidium> and
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
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
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> :)
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
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):
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: || 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

Powered by YARRSTE version: svn-trunk