--- Log opened Sat Oct 08 00:00:10 2016 20161008 00:00:34< vultraz> hm 20161008 00:00:41< vultraz> possibly for execute_hotkey 20161008 00:14:06-!- midzer_ [~quassel@p5B2968AF.dip0.t-ipconnect.de] has joined #wesnoth-dev 20161008 00:16:05-!- midzer [~quassel@p57B45DE4.dip0.t-ipconnect.de] has quit [Ping timeout: 268 seconds] 20161008 00:20:37-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds] 20161008 00:43:21< irker872> wesnoth: Charles Dang wesnoth:master 0862815e2b6e / src/gui/dialogs/lobby/ (lobby.cpp lobby.hpp): MP Lobby: minor cleanup of prefs hotkey callback handling https://github.com/wesnoth/wesnoth/commit/0862815e2b6ef9cbbb8d0c8b25ae18fc9a33712c 20161008 00:43:24< irker872> wesnoth: Charles Dang wesnoth:master a2b79720d9e5 / src/gui/widgets/helper.hpp: GUI2: removed function_wrapper helper https://github.com/wesnoth/wesnoth/commit/a2b79720d9e53b6043668a786a6b3ca2623cb6c4 20161008 00:46:01-!- gfgtdf_ [~chatzilla@x4e32b4b7.dyn.telefonica.de] has joined #wesnoth-dev 20161008 00:49:09-!- gfgtdf [~chatzilla@x4e32b4b7.dyn.telefonica.de] has quit [Ping timeout: 248 seconds] 20161008 00:49:11-!- gfgtdf_ is now known as gfgtdf 20161008 00:53:30-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev 20161008 01:01:03-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20161008 01:05:30-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 250 seconds] 20161008 01:16:31-!- gfgtdf_ [~chatzilla@x4e32b4b7.dyn.telefonica.de] has joined #wesnoth-dev 20161008 01:17:25-!- gfgtdf [~chatzilla@x4e32b4b7.dyn.telefonica.de] has quit [Ping timeout: 248 seconds] 20161008 01:17:27-!- gfgtdf_ is now known as gfgtdf 20161008 01:31:34-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!] 20161008 01:36:17-!- gfgtdf [~chatzilla@x4e32b4b7.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 49.0.1/20160922113459]] 20161008 01:54:06 * celticminstrel is not a fan of always using explicit "this". >_> 20161008 01:55:03< vultraz> neither I 20161008 01:56:20< irker872> wesnoth: Charles Dang wesnoth:master 53a60f1858cd / src/ (3 files in 2 dirs): MP Staging: colorize color choice text https://github.com/wesnoth/wesnoth/commit/53a60f1858cd56fab79dc4c6f0e496a563de9e08 20161008 01:56:36< vultraz> ugh 20161008 01:56:42< vultraz> I keep forgetting files 20161008 01:57:08< vultraz> even when i check 20161008 01:57:26< irker872> wesnoth: Charles Dang wesnoth:master e8e022b59228 / src/game_initialization/ (connect_engine.cpp connect_engine.hpp): Why do I keep forgetting files (fixup 53a60f1858cd) https://github.com/wesnoth/wesnoth/commit/e8e022b592280a0356b0810a9b4d3508fc3bb2a2 20161008 01:59:51-!- jesusalva [~jesusalva@177.96.222.137.dynamic.adsl.gvt.net.br] has joined #wesnoth-dev 20161008 02:02:07< vultraz> celticminstrel: I wonder if we can make submenus appear on hover 20161008 02:02:33< celticminstrel> Not in time for 1.13.6, I'm sure. 20161008 02:03:05< celticminstrel> In order for that to work, menus would need to be non-modal. (So either tpopup or ttip.) 20161008 02:03:19< vultraz> I see 20161008 02:03:25< celticminstrel> Mind you, the base menu should probably still be modal... 20161008 02:03:27< vultraz> they really should be, anyway 20161008 02:03:54< celticminstrel> At least, I find it convenient that it is, since it serves as a "pause" feature if I need to leave the computer and don't want to miss anything. 20161008 02:12:07< vultraz> ok, so besides the faction select dialog not showing up.. 20161008 02:12:21< vultraz> i think staging and join are mostly good 20161008 02:12:25< vultraz> they look so plain, though :/ 20161008 02:17:38< vultraz> celticminstrel: why did you oppose grouping side entries by team again? 20161008 02:18:39-!- travis-ci [~travis-ci@ec2-54-211-81-122.compute-1.amazonaws.com] has joined #wesnoth-dev 20161008 02:18:40< travis-ci> wesnoth/wesnoth#11373 (master - 53a60f1 : Charles Dang): The build was broken. 20161008 02:18:40< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/165980223 20161008 02:18:40-!- travis-ci [~travis-ci@ec2-54-211-81-122.compute-1.amazonaws.com] has left #wesnoth-dev [] 20161008 02:19:31< vultraz> then again, the idea I'm envisioning is beyond our tech 20161008 02:19:36< vultraz> since we don't have drag-and-drop 20161008 02:19:40< vultraz> or animations 20161008 02:21:35< vultraz> (I'm thinking of headers for every team, with side entries under each one that can be dragged between sections to reorder the teams) 20161008 02:21:54< celticminstrel> Did I oppose something like that? I don't remember. 20161008 02:22:03< celticminstrel> Also not entirely sure what you mean though. 20161008 02:22:36< vultraz> essentially a tree view of toggle panels where the toggle panels can be dragged between toplevel nodes 20161008 02:23:29< vultraz> our tech is not there yet :P 20161008 02:24:21< vultraz> first, we need floating widgets 20161008 02:24:31< vultraz> then we need widgets that allow for 'grabbing' 20161008 02:25:09-!- jesusalva [~jesusalva@177.96.222.137.dynamic.adsl.gvt.net.br] has quit [Ping timeout: 248 seconds] 20161008 02:25:27< vultraz> need methods to restrict movement 20161008 02:28:06< vultraz> I suppose i could also do a similar thing without drag and drop 20161008 02:28:11< vultraz> we can add/remove nodes 20161008 02:29:16< vultraz> every time you select a new controller 20161008 02:29:23< vultraz> it removes the entry from the node 20161008 02:29:29< vultraz> adds it to the appropriate one 20161008 02:30:31< vultraz> could work 20161008 02:33:57< vultraz> might be some work updating the stuff that arrives via network 20161008 02:34:08< vultraz> but it could be made to work 20161008 02:44:49-!- tad_ [~tadcarluc@173.217.65.103] has quit [Quit: Leaving] 20161008 03:05:42-!- RatArmy [~RatArmy@133.15.175.65] has joined #wesnoth-dev 20161008 03:10:46-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity] 20161008 03:11:36-!- RatArmy [~RatArmy@133.15.175.65] has quit [Ping timeout: 260 seconds] 20161008 04:11:56-!- Kwandulin [~Miranda@p200300760F2C71171DCC59541BE54FA3.dip0.t-ipconnect.de] has joined #wesnoth-dev 20161008 04:13:11< celticminstrel> [Oct 07@10:24:21pm] vultraz: first, we need floating widgets 20161008 04:13:11< celticminstrel> Floating widgets should be easy, I think. 20161008 04:13:32< vultraz> you failed to make floating widgets 20161008 04:13:48< celticminstrel> No, I failed to make floating textboxes that would work on top of the main game UI. 20161008 04:13:55< celticminstrel> The key point being "on top of the main game UI". 20161008 04:14:30< vultraz> i see 20161008 04:14:37< celticminstrel> Drag-and-drop within a GUI2 window won't have those issues, so I think it'll be easier. 20161008 04:14:45< vultraz> well fell free to work on that 20161008 04:15:51< vultraz> in the meantime i think ill implement 20161008 04:15:54< vultraz> my thing 20161008 04:27:32 * vultraz ponders data storage 20161008 04:27:39< vultraz> vector of nodes, I think 20161008 04:27:49< celticminstrel> Data storage! So vague! 20161008 04:27:55< vultraz> wait 20161008 04:28:00< vultraz> map of nodes 20161008 04:28:11-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev 20161008 04:28:18< celticminstrel> I hope you don't expect me to make recommendations when you haven't even said what you're doing. 20161008 04:28:37< vultraz> nah, map is fine 20161008 04:28:58< vultraz> (you can have references in a map, right) 20161008 04:29:36-!- iceiceice [~chris@pool-173-61-153-221.cmdnnj.fios.verizon.net] has joined #wesnoth-dev 20161008 04:29:36-!- iceiceice [~chris@pool-173-61-153-221.cmdnnj.fios.verizon.net] has quit [Changing host] 20161008 04:29:36-!- iceiceice [~chris@unaffiliated/iceiceice] has joined #wesnoth-dev 20161008 04:30:03< iceiceice> celticminstrel, you guys can revert the explicit `this->` if you want 20161008 04:30:08-!- RatArmy [~RatArmy@133.15.175.65] has joined #wesnoth-dev 20161008 04:30:12< vultraz> er 20161008 04:30:13< vultraz> wait 20161008 04:30:16< celticminstrel> I don't cate enough to bother. 20161008 04:30:17< iceiceice> i was similarly skeptical at first, but i tried it for a while, i'm convinced it's better 20161008 04:30:18< celticminstrel> ^care 20161008 04:30:19< vultraz> pointers is fine, I think 20161008 04:30:29< vultraz> i don't think references works 20161008 04:31:40< vultraz> (is that correct?) 20161008 04:32:03< celticminstrel> References are always better unless there's some reason why you can't. 20161008 04:32:12< celticminstrel> If they're in a container, that's one reason. 20161008 04:32:24< celticminstrel> You can't store references in a container. 20161008 04:32:39< celticminstrel> You should probably use a smart pointer though. 20161008 04:32:44< celticminstrel> shared_ptr or maybe weak_ptr. 20161008 04:32:57< vultraz> how would that...work 20161008 04:32:59< celticminstrel> Maybe unique_ptr if the container owns the elements. 20161008 04:33:09< celticminstrel> How would what work? 20161008 04:33:14< vultraz> I have std::map 20161008 04:33:21< vultraz> how would I use a smart ptr here 20161008 04:33:23< vultraz> and why 20161008 04:34:02< celticminstrel> Ah, I'm guessing you don't own the pointer then. Since GUI2 returns bare pointers you'll probably have to stick with a bare pointer. 20161008 04:35:55-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev 20161008 04:36:15< vultraz> hmmm 20161008 04:37:26< vultraz> ah, ok 20161008 04:37:32< vultraz> maps already have an initial team set 20161008 04:37:36< vultraz> this will make things easier 20161008 04:40:22-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20161008 04:41:03< vultraz> heh 20161008 04:41:06< vultraz> now i have this lin 20161008 04:41:08< vultraz> e 20161008 04:41:10< vultraz> ttree_view_node& node = team_tree_map_[side.controller_options()[controller_i].second]->add_child("option_checkbox_node", data); 20161008 04:41:25< vultraz> (wrong node id, ignore that) 20161008 04:42:54< iceiceice> putting a reference in a standard container is sometimes really annoying 20161008 04:44:33< iceiceice> depending which container it is i guess 20161008 04:44:33< iceiceice> because of the stuff about "a reference can only be bound once" 20161008 04:44:33< iceiceice> its sometimes very confusing to me which container will do what for instance if the container is copied or moved 20161008 04:44:33< iceiceice> idk i would recommend to use pointers in a container rather than references usually 20161008 04:44:56-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 260 seconds] 20161008 04:44:57-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 240 seconds] 20161008 04:48:03< vultraz> hmm 20161008 04:48:26< vultraz> connect engine blagh 20161008 04:50:39< iceiceice> btw i have to say, i recompiled the game to test those commits from earlier, 20161008 04:50:43< iceiceice> the gui looks really nice in master 20161008 04:50:55< vultraz> :D thanks 20161008 04:50:56< iceiceice> i'm not sure entirely all of what you guys did but it looks way more polished than in 1.12 20161008 04:51:23< vultraz> I'm responsible for the majority of the changes 20161008 04:53:35< vultraz> with help from shadowm, gfgtdf, and celticminstrel 20161008 04:55:47< celticminstrel> I did quite a few GUI things, but even then vultraz did most of the fine-tuning. 20161008 04:57:47-!- irker872 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout] 20161008 05:00:19< vultraz> hmmmm 20161008 05:00:19< vultraz> i wonder if 20161008 05:00:19< vultraz> perhaps 20161008 05:00:25< vultraz> this is a little much 20161008 05:01:13< vultraz> https://drive.google.com/file/d/0B-mR9s8FduLLYXFVZGRlS0JGcm8/view?usp=sharing 20161008 05:01:19< vultraz> though 20161008 05:01:21< vultraz> actually 20161008 05:01:24< vultraz> it could work 20161008 05:01:27< vultraz> if i move the chatbox 20161008 05:03:12< vultraz> right now it feels cramped 20161008 05:06:49< Bonobo> what are the blue >> for? 20161008 05:07:20< vultraz> buttons to select leader 20161008 05:07:48< Bonobo> that seems a little odd to me 20161008 05:08:23< Bonobo> I'd have thought the dice would be the leader select from that image 20161008 05:08:37< Bonobo> are the leaders still in a dropdown list? 20161008 05:09:21< vultraz> no 20161008 05:09:45< vultraz> all faction/leader/gender selection now uses the same dialog people get when joining a game 20161008 05:11:12< vultraz> Bonobo: ie this one https://drive.google.com/file/d/0B-mR9s8FduLLaGxQb0pLMXNXOWc/view?usp=sharing 20161008 05:11:14< Bonobo> overall it does look nicer than the old style I think 20161008 05:11:37< Bonobo> ah okay 20161008 05:12:05< celticminstrel> What's wrong with the first image? 20161008 05:12:17< vultraz> celticminstrel: it feels cramped 20161008 05:12:27< vultraz> ima try to reorganize some stuff 20161008 05:12:33< celticminstrel> Uhh... seriously? 20161008 05:12:41< celticminstrel> It seems pretty spacious to me. 20161008 05:12:54< celticminstrel> What's the north/southeast thing though? 20161008 05:13:09< vultraz> team names 20161008 05:13:20< vultraz> perhaps I'll add a "Team:" prefix 20161008 05:13:29< celticminstrel> I suppose it could get cramped on small resolutions. 20161008 05:13:41< celticminstrel> But in that screenshot it doesn't really seem cramped at all to me. 20161008 05:14:10-!- irker086 [~irker@uruz.ai0867.net] has joined #wesnoth-dev 20161008 05:14:11< irker086> wesnoth: doofus-01 wesnoth:master fd5e26935044 / data/core/images/ (8 files in 2 dirs): some edits to images/attacks and images/icons images https://github.com/wesnoth/wesnoth/commit/fd5e269350448584ba95a924faee05d0c1bb56dd 20161008 05:14:11< irker086> wesnoth: Charles Dang wesnoth:master 0d4e0b03662b / data/core/images/ (8 files in 2 dirs): Merge pull request #813 from doofus-01/icons https://github.com/wesnoth/wesnoth/commit/0d4e0b03662b7b8d6f2b6ec56f92ff23d69d1506 20161008 05:15:55< celticminstrel> How is that +0 -0 when there's a whole new file... 20161008 05:20:29< Aginor> it's not plaintext, there's no linecount 20161008 05:23:33< celticminstrel> I assumed it'd be bytecount. 20161008 05:23:40< celticminstrel> Since that's how it normally appears in git status. 20161008 05:24:05< matthiaskrgr> there is no bytecount :P 20161008 05:24:35< matthiaskrgr> I write a script however that does that matthiaskrgr/gitdiffbinstat :> 20161008 05:24:57-!- RatArmy [~RatArmy@133.15.175.65] has quit [Quit: Leaving] 20161008 05:25:01< matthiaskrgr> (compare commits by size of changed binary data ) 20161008 06:07:09-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev 20161008 06:28:38-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20161008 06:33:05-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 260 seconds] 20161008 06:52:36-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai] 20161008 06:53:03-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev 20161008 06:53:24-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Client Quit] 20161008 06:53:47-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev 20161008 06:54:12-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Client Quit] 20161008 06:54:34-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev 20161008 06:55:00-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Client Quit] 20161008 06:55:24-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev 20161008 06:55:48-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Client Quit] 20161008 06:56:13-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev 20161008 06:56:17-!- Kwandulin [~Miranda@p200300760F2C71171DCC59541BE54FA3.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds] 20161008 06:56:36-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Client Quit] 20161008 06:56:38-!- Kwandulin [~Miranda@p200300760F2C714BF86F3D921AB6948B.dip0.t-ipconnect.de] has joined #wesnoth-dev 20161008 06:56:59-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev 20161008 06:57:24-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Client Quit] 20161008 06:57:47-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev 20161008 06:58:12-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Client Quit] 20161008 07:49:59-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev 20161008 08:16:53-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20161008 08:21:25-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 248 seconds] 20161008 08:25:57-!- iceiceice [~chris@unaffiliated/iceiceice] has quit [Ping timeout: 240 seconds] 20161008 08:27:17-!- iceiceice [~chris@pool-173-61-153-221.cmdnnj.fios.verizon.net] has joined #wesnoth-dev 20161008 08:42:05-!- Kwandulin [~Miranda@p200300760F2C714BF86F3D921AB6948B.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer] 20161008 09:03:40-!- JyrkiVesterinen [~JyrkiVest@87-100-220-100.bb.dnainternet.fi] has joined #wesnoth-dev 20161008 09:04:10-!- Appleman1234 [~Appleman1@KD106154000036.au-net.ne.jp] has quit [Ping timeout: 244 seconds] 20161008 09:14:54-!- Appleman1234 [~Appleman1@KD106154000036.au-net.ne.jp] has joined #wesnoth-dev 20161008 09:21:11-!- Kwandulin [~Miranda@p200300760F2C714BB9F626CA4CCBFCB8.dip0.t-ipconnect.de] has joined #wesnoth-dev 20161008 09:28:13-!- mjs-de [~mjs-de@x4db5d908.dyn.telefonica.de] has joined #wesnoth-dev 20161008 09:41:11-!- Kwandulin [~Miranda@p200300760F2C714BB9F626CA4CCBFCB8.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer] 20161008 09:55:17-!- Kwandulin [~Miranda@p200300760F2C714BB9F626CA4CCBFCB8.dip0.t-ipconnect.de] has joined #wesnoth-dev 20161008 10:00:12-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev 20161008 10:03:17-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 248 seconds] 20161008 10:03:17-!- wedge010 is now known as wedge009 20161008 10:03:49-!- JyrkiVesterinen [~JyrkiVest@87-100-220-100.bb.dnainternet.fi] has quit [Quit: .] 20161008 10:05:11-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20161008 10:05:25-!- Duthlet [~Duthlet@dslb-188-104-253-155.188.104.pools.vodafone-ip.de] has joined #wesnoth-dev 20161008 10:09:56-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 268 seconds] 20161008 10:20:27-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20161008 10:45:34-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has joined #wesnoth-dev 20161008 10:46:33-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has quit [Client Quit] 20161008 11:02:37-!- iceiceice [~chris@pool-173-61-153-221.cmdnnj.fios.verizon.net] has quit [Ping timeout: 240 seconds] 20161008 11:13:45-!- JyrkiVesterinen [~JyrkiVest@87-100-215-158.bb.dnainternet.fi] has joined #wesnoth-dev 20161008 11:18:33-!- Kwandulin [~Miranda@p200300760F2C714BB9F626CA4CCBFCB8.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer] 20161008 11:50:55-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev 20161008 11:53:28-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20161008 11:57:46-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 244 seconds] 20161008 12:01:47-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!] 20161008 12:02:00-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20161008 12:11:31< Ravana_> Addons 1.12 server seems to be down 20161008 12:16:42 * wedge009 concurs 20161008 12:27:01-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20161008 12:27:16-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20161008 12:46:03-!- benladin [d2564fc3@gateway/web/freenode/ip.210.86.79.195] has joined #wesnoth-dev 20161008 12:47:24-!- Bonobo [~Bonobo@2001:44b8:254:3200:24e3:cfd1:579a:d8cb] has quit [Ping timeout: 260 seconds] 20161008 12:48:40-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev 20161008 12:53:26-!- benladin [d2564fc3@gateway/web/freenode/ip.210.86.79.195] has quit [Quit: Page closed] 20161008 12:53:38-!- Kwandulin [~Miranda@p200300760F2C714B88294B8E7FB1C9BC.dip0.t-ipconnect.de] has joined #wesnoth-dev 20161008 13:03:23-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has joined #wesnoth-dev 20161008 13:10:24-!- Appleman1234 [~Appleman1@KD106154000036.au-net.ne.jp] has quit [Ping timeout: 260 seconds] 20161008 13:13:47-!- Appleman1234 [~Appleman1@KD106154018217.au-net.ne.jp] has joined #wesnoth-dev 20161008 13:26:57-!- matthiaskrgr [matthiaskr@gateway/shell/panicbnc/x-gxfhduvtxvehypbj] has quit [Ping timeout: 256 seconds] 20161008 13:36:46-!- matthiaskrgr [matthiaskr@gateway/shell/panicbnc/x-uskkcvdqshamysze] has joined #wesnoth-dev 20161008 13:37:11-!- matthiaskrgr is now known as Guest34788 20161008 13:50:49-!- iceiceice [~chris@pool-173-61-153-221.cmdnnj.fios.verizon.net] has joined #wesnoth-dev 20161008 13:57:57-!- iceiceice [~chris@pool-173-61-153-221.cmdnnj.fios.verizon.net] has quit [Ping timeout: 240 seconds] 20161008 13:58:06-!- irker086 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout] 20161008 14:38:12-!- irker501 [~irker@uruz.ai0867.net] has joined #wesnoth-dev 20161008 14:38:12< irker501> wesnoth: Jyrki Vesterinen wesnoth:master 19358294be01 / src/gui/widgets/ (control.cpp listbox.cpp scrollbar_container.cpp scrollbar_container.hpp): GUI2 MP lobby: fix the game list jumping to top when a new game starts https://github.com/wesnoth/wesnoth/commit/19358294be01c2718d71abbde3b89eab3aba99ad 20161008 14:47:12-!- atarocch [~atarocch@host246-63-dynamic.35-79-r.retail.telecomitalia.it] has joined #wesnoth-dev 20161008 14:51:35-!- Kwandulin [~Miranda@p200300760F2C714B88294B8E7FB1C9BC.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer] 20161008 15:05:18-!- Kwandulin [~Miranda@p200300760F2C714B88294B8E7FB1C9BC.dip0.t-ipconnect.de] has joined #wesnoth-dev 20161008 15:18:46-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has quit [Quit: horrowind] 20161008 15:35:35< zookeeper> celticminstrel, "The .word[0] syntax also requires 1.13.5 or so." uh what? we have syntax like that? 20161008 15:39:07< zookeeper> i would have bet money that the guy was just pulling that syntax out of their, uh, hat 20161008 15:53:37-!- boucman_work [~boucman@2a02-8428-034f-f800-9e32-0c7c-b391-6223.rev.sfr.net] has joined #wesnoth-dev 20161008 15:57:46< zookeeper> oh, in formulas only? well that would explain why i'd not have any idea 20161008 16:03:39-!- atarocch [~atarocch@host246-63-dynamic.35-79-r.retail.telecomitalia.it] has quit [Remote host closed the connection] 20161008 16:04:15< pydsigner> Guys is the 1.12 addons server down? 20161008 16:04:44< zookeeper> so they say 20161008 16:04:48-!- DeFender1031 [~DeFender1@89-138-252-80.bb.netvision.net.il] has joined #wesnoth-dev 20161008 16:05:48< pydsigner> Hmm so they do 20161008 16:06:12< pydsigner> Is shadowm in charge of that? I haven't seen him in a while 20161008 16:09:07< pydsigner> The web interface is still up 20161008 16:29:28-!- Nikitaw99 [2e005019@gateway/web/freenode/ip.46.0.80.25] has joined #wesnoth-dev 20161008 16:29:38< Nikitaw99> hi 20161008 16:30:24< Nikitaw99> I just started a devlog for my battle for wesnoth campaign http://wesnoth-theinvasion.tumblr.com/ 20161008 16:30:26< Nikitaw99> :p 20161008 16:34:14< DeFender1031> zookeeper, gfgtdf, about post-scenario-end events, i noticed yesterday that in debug mode, you can still shift-k units after the scenario end, and that doing so actually triggers events (at least in 1.12) 20161008 16:36:25-!- boucman_work [~boucman@2a02-8428-034f-f800-9e32-0c7c-b391-6223.rev.sfr.net] has quit [Remote host closed the connection] 20161008 16:38:31< DeFender1031> ah, [have_unit] not matching units with health not greater than 0. I literally encountered that myself yesterday. (Wanted to check if the dying unit was within a certain set of hexes (had a set of x and y for them), so i did [have_unit] with id=$unit.id, x=$x_range, and y=$y_range and it didn't work ended up switching to [have_location] with x,y=$unit.x,$unit.y and an [and] containing the ranges. 20161008 16:44:45< Nikitaw99> how do i enable debug mode? 20161008 16:44:51< DeFender1031> zookeeper, tad_, gfgtdf, would it not make sense to delay the execution of [endlevel] (dimming the screen, linger mode, showing the report, etc.) until after all events which would normally happen after the most recent action have happened? 20161008 16:45:12< pydsigner> Nikitaw99: :debug 20161008 16:45:51< Nikitaw99> pydsigner: in where? 20161008 16:46:13< pydsigner> colon brings up the command entry box 20161008 16:46:18< pydsigner> debug is what you type there 20161008 16:46:31< pydsigner> While in-gam 20161008 16:46:34< pydsigner> * in-game 20161008 16:47:55< Nikitaw99> pydsigner: oh okay, thanks! 20161008 16:50:14-!- ancestral [~ancestral@63.236.20.2] has joined #wesnoth-dev 20161008 16:51:27-!- ancestral [~ancestral@63.236.20.2] has quit [Client Quit] 20161008 17:13:20-!- Kwandulin [~Miranda@p200300760F2C714B88294B8E7FB1C9BC.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer] 20161008 17:21:35-!- gfgtdf [~chatzilla@x4e3637fb.dyn.telefonica.de] has joined #wesnoth-dev 20161008 17:31:26-!- Nikitaw99 [2e005019@gateway/web/freenode/ip.46.0.80.25] has quit [Quit: Page closed] 20161008 17:38:12-!- irker501 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout] 20161008 17:40:46-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity] 20161008 17:40:55-!- tad_ [~Gregory@173.217.65.103] has joined #wesnoth-dev 20161008 17:42:37< tad_> gfgtdf, On my GL_Lua branch: If I dropped change for locale due to controversy, would you object to a PR with the other changes going in for 1.13.6? 20161008 17:43:13< tad_> zookeeper, Do you have any plans for my DM and/or THoT PRs going into 1.13.6? 20161008 17:43:46< zookeeper> if i can check them in time, sure 20161008 17:44:43< tad_> zookeeper, Totally up to you. As far as I'm concerned both are ready, pending your approval or requests. 20161008 17:45:59-!- midzer_ is now known as midzer 20161008 17:47:57< gfgtdf> tad_: is see no rpblems with 1cae2964f5633ccc93610eeda86794bf698da646 and 6f46e5c5da370c6d9fca58df6ef7ba38a625771c, 20161008 17:48:19< gfgtdf> tad_: if whats said in the commtimessagea of a3163325d047d6a59b75efe8a30f10510eb89275 is true then this is godo asdwell 20161008 17:49:01< gfgtdf> tad_: the orignial commit said that it was found by coverty, so i wonder whetehr coverty was incorrect? 20161008 17:50:12< gfgtdf> tad_: or maybe ias original commit was correct and thne it was fixed with lua 5.2 so that the fix was thne "teice" in it ? 20161008 17:50:31< tad_> gfgtdf, He must have been. It was part of a larger overrun check which was correct, I think this one change was an easy mistake to make. Thankfully, it's not possible to have \U0100 treated as a one-byte character. 20161008 17:50:56< tad_> gfgtdf, I checked against the version he changed. It was wrong back then, too. 20161008 17:51:29< gfgtdf> tad_: 1111f7320ca2a5f42b345f91a4da87b5bd96a23c looks good to me too 20161008 17:51:52< gfgtdf> tad_: does te branch change the exception handing stuff? 20161008 17:52:35< gfgtdf> handling* 20161008 17:53:20< tad_> Not yet. I should do that but I was thinking the obvious stuff in those could go in simply as prep for upgrading. 20161008 17:53:34< vultraz> JyrkiVesterinen: :D 20161008 17:54:45< tad_> gfgtdf, Would you prefer changes to exception handling be prioritized for 1.13.6? 20161008 17:55:31< gfgtdf> tad_: no my question was just whether i am missng something. 20161008 17:55:47< gfgtdf> was* 20161008 17:56:08< gfgtdf> overlooked* 20161008 17:58:14< tad_> gfgtdf, OK, then I shall remove the two locale changes and make a PR. If there is time (probably won't take but a few minutes) I may refactor that strcoll->strcmp from a source edit to a #define in luaconf.h which is the only file I think we should change when upgrading (locality of control) 20161008 17:59:23-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!] 20161008 18:00:32< gfgtdf> tad_: ok 20161008 18:14:16< gfgtdf> is the 'wesoth crashed when starting a campaign' issue fixed? 20161008 18:15:30< tad_> I was able to reproduce it when first reported but cannot any longer. My vote is: it was fixed. Don't ask how or why. 20161008 18:15:56< vultraz> zookeeper: please merge 814 if it's good 20161008 18:22:49 * tad_ suddenly realizes why color themes are so important. He wasted 15 minutes in a panic not finding the website project because he was using Netbeans on the wrong system. 20161008 18:28:26-!- Guest34788 [matthiaskr@gateway/shell/panicbnc/x-uskkcvdqshamysze] has quit [Changing host] 20161008 18:28:27-!- Guest34788 [matthiaskr@unaffiliated/matthiaskrgr] has joined #wesnoth-dev 20161008 18:28:27-!- Guest34788 [matthiaskr@unaffiliated/matthiaskrgr] has quit [Changing host] 20161008 18:28:27-!- Guest34788 [matthiaskr@gateway/shell/panicbnc/x-uskkcvdqshamysze] has joined #wesnoth-dev 20161008 18:28:33-!- gfgtdf [~chatzilla@x4e3637fb.dyn.telefonica.de] has quit [Remote host closed the connection] 20161008 18:28:45-!- Guest34788 is now known as matthiaskrgr 20161008 18:33:56< celticminstrel> [Oct 08@11:35:35am] zookeeper: celticminstrel, "The .word[0] syntax also requires 1.13.5 or so." uh what? we have syntax like that? 20161008 18:33:57< celticminstrel> In WFL, yes; I added it 20161008 18:37:48-!- tad_ [~Gregory@173.217.65.103] has quit [Quit: Leaving] 20161008 18:38:10-!- mjs-de [~mjs-de@x4db5d908.dyn.telefonica.de] has quit [Remote host closed the connection] 20161008 19:00:55-!- tad_ [~tadcarluc@173.217.65.103] has joined #wesnoth-dev 20161008 19:04:29< vultraz> i just remembered 20161008 19:04:48< vultraz> we never added back that Starting Scenario feature in the GUI2 mp conversion 20161008 19:06:18-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20161008 19:06:54< vultraz> Entry Point 20161008 19:06:57< vultraz> that's what it was called 20161008 19:07:05< vultraz> I wonder if this is bad 20161008 19:09:52< vultraz> actually, I know how it could come back 20161008 19:10:15< vultraz> a simple item selection dialog popup where Configure used to be 20161008 19:18:35< vultraz> it means 2 loading screens though 20161008 19:18:37< vultraz> or maybe not? 20161008 19:20:18< vultraz> yeah, probably not 20161008 19:20:28< vultraz> just setting the current scenario config 20161008 19:22:48< celticminstrel> Simple item selection as in the dialog used by ;choose_level 20161008 19:23:52-!- JyrkiVesterinen [~JyrkiVest@87-100-215-158.bb.dnainternet.fi] has quit [Quit: .] 20161008 19:32:19< DeFender1031> zookeeper, tad_, gfgtdf, I said this earlier, but you weren't actually here then, so I'll say it again: regarding the conversation yesterday abount endlevel and die eventss, would it not make sense to delay the execution of [endlevel] (dimming the screen, linger mode, showing the report, etc.) until after all events which would normally happen after the most recent action have happened? 20161008 19:34:11< zookeeper> isn't that exactly how it works now? 20161008 19:34:32< zookeeper> because i'm pretty sure it does 20161008 19:35:14< DeFender1031> dunno, i'm on 1.12, but from the dicussion yesterday, it seemed like calling [endlevel] in a last breath would cause the game to perform the endlevel stuff and only trigger the die events after that. 20161008 19:35:29< DeFender1031> unless i totally misunderstood the entire premise of the discussion 20161008 19:35:47< zookeeper> yeah that wasn't part of the problem at all 20161008 19:36:07< DeFender1031> then ignore me. 20161008 19:36:44< DeFender1031> (though I am curious now what the issue actually being discussed was) 20161008 19:37:16< tad_> The die event was not triggering if it had no filter at all and [endlevel] was performed during last breath. 20161008 19:38:01< zookeeper> the problem was the change in behavior between 1.12 and 1.13 regarding what happens to following die events if a last breath event [endlevel]s. 20161008 19:38:04< DeFender1031> that part i got, but then there seemed to be some concern over enabling it because then a mundane die event might end up happening after the [endlevel] 20161008 19:38:25< DeFender1031> which would look weird 20161008 19:38:27< DeFender1031> or something 20161008 19:39:33< tad_> DeFender1031, I don't recall that being discussed but I might have missed it; it is a valid point and probably deserves a quick test comparing 1.12.6 and +dev for consistency. 20161008 19:39:56< DeFender1031> let me find the line that I interpreted that way... 20161008 19:40:15 * tad_ shrugs. Or just run out and test it. 20161008 19:41:09< DeFender1031> 20161007 18:15:54< zookeeper> the main problem i'm worrying about is, like in TRoW:06, a last breath event declaring victory/defeat (very very common) and an unrelated die event for some mundane death commentary or such. 20161008 19:41:20< DeFender1031> tad_, i meant line of chatlog, not code :P 20161008 19:41:36 * tad_ nods. 20161008 19:43:50-!- ancestral [~ancestral@209.181.254.220] has joined #wesnoth-dev 20161008 19:46:15-!- irker559 [~irker@uruz.ai0867.net] has joined #wesnoth-dev 20161008 19:46:15< irker559> wesnoth: doofus-01 wesnoth:master ca83f5028c72 / data/core/ (29 files in 2 dirs): some variations and better cropping for aquatic castle walls (#814) https://github.com/wesnoth/wesnoth/commit/ca83f5028c72a12d8f4769197b8709e90925526b 20161008 19:46:23< zookeeper> is there any particular reason to choose "create a merge commit" over "rebase and merge"? 20161008 19:49:00< tad_> arjanvandergaag.nl/blog/clarify-git-history-with-merge-commits.html 20161008 19:53:29< zookeeper> i take that as a "no" 20161008 19:57:25< tad_> I take it as a matter of personal preference / project standards. 20161008 19:59:15< tad_> To-MAY-to To-Mah-to 20161008 19:59:29< vultraz> To MAY to :P 20161008 20:02:27< vultraz> celticminstrel: https://drive.google.com/file/d/0B-mR9s8FduLLYXFVZGRlS0JGcm8/view?usp=sharing 20161008 20:02:57< vultraz> still might change the background 20161008 20:09:43< vultraz> actually, will change the background 20161008 20:11:28< vultraz> we don't have enough bleak art 20161008 20:13:26-!- ancestral [~ancestral@209.181.254.220] has quit [Quit: i go nstuf kthxbai] 20161008 20:14:43< vultraz> t'is art too sunny! 20161008 20:14:48< vultraz> this* 20161008 20:16:47< tad_> Very pretty. 20161008 20:17:29< vultraz> what would be appropriate for this screen is a shot of a dark creepy, mist forest 20161008 20:17:55-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV] 20161008 20:18:37< tad_> Something to think about for the future would be doing something like that a LOT of places. 20161008 20:18:54< vultraz> what lot? 20161008 20:19:37-!- gfgtdf [~chatzilla@x4e3637fb.dyn.telefonica.de] has joined #wesnoth-dev 20161008 20:19:42< tad_> Campaign selection? Difficulty selection? Preferences? Who knows. It's pretty and I like it. 20161008 20:20:29< vultraz> much more art is needed 20161008 20:21:10< tad_> gfgtdf, I'm looking at the history of changes to ~src/lua/luaconf.h and checking into what will be needed for a Lua upgrade to 5.3.3 and .. oh, boy .. loooks like NONE of the changes Wesnoth made there will be needed ... 20161008 20:21:26< vultraz> dota 2 effectively uses art as backgrounds in places, and I've tried to emulate that, but I've not been.. entirely successful. 20161008 20:21:32< vultraz> mostly because of the limited selection 20161008 20:21:38< vultraz> we have 20161008 20:21:51< tad_> Except for compatability to Lua 5.1 and/or Lua 5.2 ... which we can talk about when I'm closer to upgrading. 20161008 20:22:08< vultraz> but, as a board member, I can propose a commission of new story art. 20161008 20:22:29< vultraz> just doesn't help me *right now* :| 20161008 20:22:55< gfgtdf> tad_: hmm so how yre you goaing to iplement those things there instead ? 20161008 20:23:23< gfgtdf> are* 20161008 20:24:07< tad_> gfgtdf, The change for IEEE754 goes away, not needed. The change for a warning on fwrite goes away, bug fixed, not needed. The change for reserving space for a back point, already there, not needed. 20161008 20:25:16< tad_> gfgtdf, looks like the only issues are backward compatability and, possibly, suppressing __STRICT_ANSI__ (if we need that, haven't checked that yet) 20161008 20:26:11< tad_> gfgtdf, And the compatibility changes really should be done as preprocessor options, now file edits. 20161008 20:26:19< tad_> s/now/not/ 20161008 20:26:44< vultraz> But I suppose "my project needs more funding" is a universal problem 20161008 20:28:05< tad_> vultraz, Well, you could approach Google, or do a GoFundMe or Kickstarter campaign. Seems the bored members will have some thinking to do. 20161008 20:28:35< vultraz> We need to get donations set up 20161008 20:28:41< vultraz> So people will giff moniez. 20161008 20:29:43< tad_> Which means a war chest bank account. Which means company officers for the board to hire/appoint to handle it. Which means ... 20161008 20:30:20< vultraz> we have everything under control :) 20161008 20:30:32< tad_> Remember, the job of a Board of Directors is to 'direct' .. not necessarily 'do' 20161008 20:30:54< vultraz> Yes, well, we don't really have anyone to direct :P 20161008 20:31:02< vultraz> So we're also the do-ers 20161008 20:31:11-!- atarocch [~atarocch@host246-63-dynamic.35-79-r.retail.telecomitalia.it] has joined #wesnoth-dev 20161008 20:31:52< gfgtdf> tad_: i wonder what the warnign on fwrite does? afaikw we overwrite print with our own custom print function that writes t lua console 20161008 20:32:05< zookeeper> so i got crashes when starting any campaign. then i pulled, re-compiled, and it went away. okay, someone fixed it, great. now i get it again, and i haven't done anything since. 20161008 20:32:24< tad_> The issue was a compiler warning about the results not being used. That has been corrected in Lua 5.3 so we don't need that change at all. 20161008 20:33:21< tad_> zookeeper, I had the same funny feeling when I was trying to reproduce it. I could, I rolled back and still could. I bisected and could not. It has not come back since, for me. 20161008 20:34:37< tad_> zookeeper, BUT after doing all that I hit a git issue with garbage collection. So I compressed and pruned (and hand-deleted a garbage file) ... so it might be a git issue. 20161008 20:35:35< gfgtdf> tad_: you know what hapend to the IEEE754 trick? i cannot find it in the lua 5.3 code at all. 20161008 20:36:25< tad_> gfgtdf, Lua appears to have gone over to fully IEEE754 and I think there's a note about that on their history/changelog page ... I'd have to check again, though. 20161008 20:36:36< vultraz> tad_, zookeeper: crash is likely related to de8a4270a4aee6cd405d5a9abf4a5034c96e451e 20161008 20:37:08< gfgtdf> tad_: i cannot find __STRICT_ANSI__ word in the lua 5.3 code eigher. 20161008 20:38:23< tad_> gfgtdf, Well, the stated goal for Lua is to always be strict "ANSI" .. now IEC/ISO .. so I'm not surprised. 20161008 20:38:43< zookeeper> i forgot, what's a good and light and fast pastebin alternative? 20161008 20:39:05< tad_> vultraz, What is the title of that commit? I don't see it on master but I may be blind. 20161008 20:39:30< vultraz> https://github.com/wesnoth/wesnoth/commit/de8a4270a4aee6cd405d 20161008 20:39:31< zookeeper> vultraz, well i got this stacktrace of the crash: https://paste.ee/p/5TvxY 20161008 20:39:32< tad_> vultraz, If it's that big change for MSVC warnings about masked variables, I concur but cannot prove. 20161008 20:39:42< DeFender1031> vultraz, the MP screen you pasted above looks very nice. 20161008 20:43:08< gfgtdf> that seems to be teh same erro as in http://gna.org/bugs/index.php?25144, where we also came to the comclusion that it was that commit 20161008 20:44:09-!- mjs-de [~mjs-de@x4db5d908.dyn.telefonica.de] has joined #wesnoth-dev 20161008 20:44:34< vultraz> yeah 20161008 20:44:38< vultraz> but im not sure the "proper" fix 20161008 20:44:55< gfgtdf> vultraz: you mena reverting it ? 20161008 20:44:55< vultraz> as to* 20161008 20:45:05< vultraz> no, I don't want to revert it 20161008 20:45:20< vultraz> it's necessary 20161008 20:46:32< gfgtdf> so what was not the proper fix ? 20161008 20:47:03< vultraz> I don't know what the fix is, I mean 20161008 20:49:25< gfgtdf> vultraz: you coudl try to call prepare_for_new_level() after get_parameters() 20161008 20:49:39< gfgtdf> (instead of before) 20161008 20:51:27< vultraz> i can't really tell if that would work since i don't get the crash 20161008 20:52:14< zookeeper> well surely that needs to be fixed one way or another before the release anyway 20161008 20:52:31< gfgtdf> zookeeper: do you get the crash reliables so that you can text it ? 20161008 20:52:42< zookeeper> seems so 20161008 20:52:59< vultraz> zookeeper: I'm not sure how you propose changing the stone walls :/ 20161008 20:53:09< zookeeper> vultraz, making them take as little space as possible 20161008 20:53:27< vultraz> yes, but that might break every dungeon map ever 20161008 20:53:31< zookeeper> south-facing walls up a bit, north-facing walls down a bit, etc 20161008 20:53:34< zookeeper> i doubt it 20161008 20:55:03< vultraz> we'd have to see it in action 20161008 20:55:29< zookeeper> well yeah, usually that's necessary when doing graphics work :P 20161008 20:56:08< zookeeper> this wouldn't break anything any more than any other terrain graphics upgrade does 20161008 20:56:36< vultraz> well, as long as you don't significantly change the layout 20161008 20:57:00< zookeeper> how would one even change the layout of walls? 20161008 20:57:22< vultraz> ie, don't get rid of the 2-hex flats 20161008 20:57:47< zookeeper> yes, that wasn't part my suggestion 20161008 20:57:50< gfgtdf> zookeeper: coudl you plseach check if whether teh error goes away if you switch these 2 lines : https://github.com/wesnoth/wesnoth/blob/master/src/game_initialization/singleplayer.cpp#L137 ? 20161008 20:58:18< vultraz> (why is it always that when I'm the one being cautious, you're not, and vice-versa :P ) 20161008 21:02:39< zookeeper> gfgtdf, apparently i can't do that right now, but in half an hour or so... 20161008 21:05:35< gfgtdf> ok 20161008 21:09:22< vultraz> gfgtdf: do you have any idea why this dialog might not be showing here: https://github.com/wesnoth/wesnoth/blob/master/src/gui/dialogs/multiplayer/mp_join_game.cpp#L205 20161008 21:12:28< gfgtdf> vultraz: no, 20161008 21:12:45< gfgtdf> vultraz: maybe its the same issue why teh addon opstions don't show 20161008 21:13:13< gfgtdf> vultraz: does that dialog work when used form the gui1 mpwait ? 20161008 21:13:36< vultraz> yeah and it works when used in the staging dialog 20161008 21:14:52< gfgtdf> vultraz: so what happens is that dialo just skipped or does it get stuck there? 20161008 21:15:05< vultraz> stuck 20161008 21:15:07< vultraz> never shows 20161008 21:15:16< vultraz> ive confirmed it goes through the preshow functions 20161008 21:15:28< vultraz> and gets all the way to the window->show command 20161008 21:15:30< vultraz> and hen stops 20161008 21:15:56< gfgtdf> vultraz: what hapen when you resize the window while that doeg doent show ? 20161008 21:17:44< gfgtdf> doesn't 20161008 21:22:05< celticminstrel> vultraz: I'd much rather see new portraits (mainly for the khalifate) than new story art (assuming you have to choose between them). Of course it'd also be great if we have both. 20161008 21:23:03< vultraz> gfgtdf: still doesn't show and the loadscreen doesn't resize properly 20161008 21:23:42< vultraz> celticminstrel: honestly, I think we'd do NR portraits before the Khalifate 20161008 21:23:48< vultraz> since NR is the last campaign needing them 20161008 21:24:01< vultraz> we don't have unlimited monies, though 20161008 21:24:09< vultraz> (not sure why tad_ said "go to google") 20161008 21:24:43< celticminstrel> If I recall correctly, NR has portraits, so I'd prioritize khalifate since they don't even have any. 20161008 21:25:18< gfgtdf> vultraz: hmm but when you had the difficuly dialog in the post_show event of the gui2 mo_Create it did work right ? 20161008 21:25:49< vultraz> gfgtdf: it's not in post_show, it's in the exit hook 20161008 21:25:57< vultraz> ie, it fires while the dialog is open 20161008 21:26:11< vultraz> but it did work when it was in post_show, yeah.. 20161008 21:26:30< vultraz> I've tried moving the code to mp_join_game's pre_show but that doesn't work either :/ 20161008 21:26:52< tad_> Well, Google's been funding some open source projects. Might be able to convince them to help. Probably not, but there are a lot of funding organizations out there. 20161008 21:28:18< tad_> Personally, what I'd try is getting some uni art departments interested in donating art as class assignments. 20161008 21:29:04< gfgtdf> vultraz: no idea currently, unfortnuteley i cannot debug this currently which woudl othewise be teh next step. 20161008 21:31:00< tad_> gfgtdf, Fixing strcoll -> strcmp in luaconf is a non-starter because luaconf is included in the src/ai/lua functions. So, the old comment about memcmp optimization is a good idea, what I should do that for the PR for 1.13.6? 20161008 21:31:47< gfgtdf> tad_: dies luaconf offer a special hoo for changin that function? 20161008 21:33:18< tad_> gfgtdf, No. #define causes conflict with C standards in src/ai. NB that this change precludes ever being able to use LuaJIT without a lot of pain. 20161008 21:33:39< gfgtdf> tad_: the memcmp optimisation sounds like it has some nonzero chance of beeing done wrong, so i think we shoduln put this into wesnoth 1.12.6 20161008 21:34:45< gfgtdf> tad_: since strcoll has issues on windows liek i said in the commits discussion, i think ths safe to asume that none of the codes in wesnoth use that function. and if yes we shodul change those codes to use teh function from gettext.hpp instead 20161008 21:35:09< tad_> gfgtdf, OK. We do want to revisit this as regards the discussion you and celmin have been having on the backed-off commits on my branch. 20161008 21:36:33< celticminstrel> "i think ths safe to asume that none of the codes in wesnoth use that function" -- He explicitly said a number of times that strcoll is being used for sorting help topics or something. 20161008 21:36:45< celticminstrel> We should change this to use translation::icompare or something, though. 20161008 21:37:20< tad_> gfgtdf, The issue is that a string literal in Lua will be "C" locale unless run through wesnoth _() function so we will always have an issue in Lua unless we do a lot of handwaving. 20161008 21:37:56< gfgtdf> celticminstrel: 'and if yes' actualyl menat 'and if there is wesnoth code that use that function' 20161008 21:38:16< tad_> celticminstrel, The help topic sort is a separate issue, not related to Lua, and really SHOULD be fixed. At present it's "not my yob, mon." 20161008 21:38:52< celticminstrel> Sure. 20161008 21:39:11< celticminstrel> gfgtdf: I know what "and if yes" meant. 20161008 21:43:28< gfgtdf> tad_: hm hmm having to wetite _(str) > _(str) instead of str > st2r2 to get a to sort user visible but 'already translated' strings, looks like an acceptable solution to me. 20161008 21:44:11< gfgtdf> tad_: if this has disadvantages in speed or similar we coudl also just expost the translations::compare function to lua. 20161008 21:44:21< tad_> gfgtdf, As I said "handwaving" .. 20161008 21:44:54-!- atarocch [~atarocch@host246-63-dynamic.35-79-r.retail.telecomitalia.it] has quit [Remote host closed the connection] 20161008 21:45:12< gfgtdf> tad_,. i ignored that word becasue i didnt know what it meant, wil look it up 20161008 21:45:50< tad_> gfgtdf, After changing strcoll to strcmp we need to be sure it's well documented that, in Lua for Wesnoth, one MUST NOT use string.sort or < > <= >= on 'normal' strings extracted from the userdata tstring. 20161008 21:46:36< gfgtdf> tad_: you mean table.sort ? 20161008 21:46:49< tad_> Our Lua will 'do the right thing' (speed may be an issue but it will do the right thing) so long as you keep 'normal' "C" locale strings separate from userdata tstrings. 20161008 21:47:13< tad_> gfgtdf, Correct. Wetware data retrieval error. 20161008 21:48:55< tad_> Lua will punt the comparisons involving userdata over to our C++ implementation. So we just need to either disallow or wave our hands about extracting localized strings and doing comparisons other than == or !== 20161008 21:49:17< gfgtdf> tad_: i wonder whether there is any other case where the lua uises c locales (which do not wiron un windows with utf8) 20161008 21:50:04< gfgtdf> work on* 20161008 21:50:07< tad_> gfgtdf, Given your (correct) comments, all 'stock' Lua on Windows will exhibit collation bugs if the locale is changed. 20161008 21:51:15< tad_> gfgtdf, To be honest, this is an issue which should be kicked upstream to PUC-Rio 20161008 21:54:41< vultraz> celticminstrel: what's the problem with help? 20161008 21:55:36< gfgtdf> vultraz: it uses the strcoll function 20161008 21:55:39< tad_> vultraz, There is a sort for topics which uses strcoll() and should be changed to use the Boost localized string compare because it's working on localized strings 20161008 21:55:56< vultraz> why is it sorting by translated strings...? 20161008 21:56:04< tad_> vultraz, Topic list. 20161008 21:56:23< vultraz> yes, but why not non-translatable ID. 20161008 21:57:09< tad_> vultraz, So the topics are sorted by the local language and make more sense to the non-English-reading user. 20161008 21:57:15< vultraz> I guess.. 20161008 21:57:48< vultraz> I guess when we switch help to gui2 we'd just compare tstr.str() 20161008 21:57:56< celticminstrel> vultraz: Yeah, don't sort by topic ID, that's silly. 20161008 21:58:02< tad_> In French accented e goes between normal e and normal f. But on Windows it won't sort correctly because we're using strcoll. 20161008 21:58:30-!- tad_ [~tadcarluc@173.217.65.103] has left #wesnoth-dev ["Leaving"] 20161008 21:58:31< vultraz> (I assume tstr.str() takes translations into account) 20161008 21:58:41< celticminstrel> vultraz: What we'll do is replace strcoll() with translation::icompare. They have the same interface, so it shouldn't be hard. 20161008 21:58:56-!- tad_ [~tadcarluc@173.217.65.103] has joined #wesnoth-dev 20161008 21:58:58< vultraz> (since I use that copiously) 20161008 21:59:05< vultraz> (so I'd hope so) 20161008 21:59:12< celticminstrel> vultraz: tstr.str() is the translated string, yes. .base_str() is the untranslated encoded form. 20161008 22:00:12-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev 20161008 22:00:36< tad_> We do not notice the sort error on help topics on non-Windows because the locale is left set correctly and strcoll is only a problem for windows because windows does NOT use UTF-8, it uses UCS-16 for localized strings. 20161008 22:01:27< vultraz> celticminstrel: and > works correctly on the translations? 20161008 22:01:56< celticminstrel> vultraz: Well, no. 20161008 22:02:28< celticminstrel> tstr1.str() < tstr2.str() won't give you the correct result, in general. 20161008 22:03:17-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 248 seconds] 20161008 22:03:17-!- wedge010 is now known as wedge009 20161008 22:03:39< vultraz> so you mean all the cases in my dialogs that sort by tstr.str() won't work with translations? :| 20161008 22:03:47< celticminstrel> Correct. 20161008 22:03:54< vultraz> Well fuck. 20161008 22:03:57< vultraz> :| 20161008 22:04:39< celticminstrel> It'll give sort of sensible results, at least. 20161008 22:04:50< vultraz> so what should be done in that case? 20161008 22:04:56< celticminstrel> But, it won't necessarily be the correct collation for the desired locale. 20161008 22:05:20< tad_> Actually, the conditions are probably such that it will "usually" be correct. It depends upon the strings. If they're close, in the right way, your code will show the error. 20161008 22:05:31< celticminstrel> Yes. 20161008 22:05:38-!- Duthlet [~Duthlet@dslb-188-104-253-155.188.104.pools.vodafone-ip.de] has quit [Quit: leaving] 20161008 22:06:17< vultraz> Starting to see why most indie games don't have translations :| 20161008 22:06:26< tad_> My supposition is either the people who see the errors (if any actually appear) are so used to seeing such errors they're not reporting them. Or the translators are aware of it andworking around the issues when they can 20161008 22:06:31< celticminstrel> The proper way to do "tstr1 OP tstr2" is currently "translation::compare(tstr1, tstr2) OP 0". 20161008 22:06:39< celticminstrel> Where OP can be any of < <= > >= == != 20161008 22:07:01< celticminstrel> Also you might prefer icompare instead of compare, for case-insensitive comparisons. 20161008 22:07:06< celticminstrel> (Which usually make more sense.) 20161008 22:07:11< tad_> Oh geez .. can you PLEASE put in some operators to fix that? 20161008 22:07:36< celticminstrel> In t_string? Probably. It'd be trivial to add < <= > >= implemented in terms of translation::compare. 20161008 22:07:39< vultraz> is there any reason tstring::operator< and operator> can't do that. 20161008 22:08:07< celticminstrel> vultraz: Well, even if tstring::operator< did that, I think it'd still make sense to manually use icompare instead of the case-sensitive operator<. 20161008 22:08:15< tad_> tstr1 < tstr2 ==> tstr1::operator<(tstr2) and vultraz just needs to loose the .str() bit. 20161008 22:08:55< vultraz> if the interface was simply to use < and > on the tstrings I'd be very happy 20161008 22:09:19< tad_> Except, of course, if you want to be case insensitive. They you'd have to use the underlying functions ... 20161008 22:09:31< vultraz> That would fit perfectly with GUI2's listbox sorting algorithm. 20161008 22:10:08< celticminstrel> You can't just bind compare() or icompare() as a comparator in GUI2 or a standard container. 20161008 22:10:31< celticminstrel> They use the ternary interface of strcmp, not the binary interface of operator< 20161008 22:11:00< vultraz> yes, my point is that you wouldn't 20161008 22:11:07< vultraz> just use > or < on the tstring 20161008 22:11:16< vultraz> and have the tstring class implement the operators 20161008 22:11:33< celticminstrel> My point is that that will give surprising results in some edge cases. 20161008 22:11:39-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Read error: Connection reset by peer] 20161008 22:12:07< celticminstrel> Listboxes should probably be sorted with icompare, in general. 20161008 22:12:18< tad_> gfgtdf, On the PR I have up: the remaining issues I have with modifications to the stock Lua source code are all sufficiently complex and wesnoth-specific that I envision no further work on PR 815 until I upgrade to Lua 5.3.3 20161008 22:12:31< vultraz> celticminstrel: why? 20161008 22:12:31< celticminstrel> You could argue "just implement operator< with icompare", but I feel that violates principle of least surprise. 20161008 22:12:42< vultraz> celticminstrel: and any reason we can't use a user literal operator for icompare? 20161008 22:12:50< celticminstrel> ... 20161008 22:13:01< celticminstrel> That shows a total lack of understanding of what a user literal operator is. 20161008 22:13:13< vultraz> perhaps :P 20161008 22:13:14< celticminstrel> Also, we can't use them because MSVC 2013 (and XCode 4) do not support them. 20161008 22:13:19< tad_> gfgtdf, So, if noone has any further issues with it, please merge at your leasure. 20161008 22:13:39< vultraz> you cannot expect me to know everything 20161008 22:15:31< celticminstrel> A user literal operator is a new way of constructing an object. 20161008 22:15:44< celticminstrel> It's not a way of implementing arbitrary custom operators. 20161008 22:15:44< vultraz> oh god, another one? 20161008 22:16:03< celticminstrel> Yes, so you can write "some string"_s instead of std::string("some string"). 20161008 22:16:13< celticminstrel> (I think that's actually in the standard in C++14 or C++17.) 20161008 22:16:39< vultraz> alright, fine 20161008 22:16:57< vultraz> but you haven't said why the listbox should ignore case 20161008 22:17:15< celticminstrel> Case-insensitive comparison is, in my opinion, more intuitive. 20161008 22:17:18< vultraz> that's not usual ux behavior 20161008 22:17:40< celticminstrel> I think people would be more surprised by case-sensitive ordering than by case-insensitive ordering. 20161008 22:17:54< celticminstrel> Please back up your last statement. 20161008 22:18:02< tad_> I don't think it matters just so long as it's CONSISTENT. 20161008 22:18:23< celticminstrel> Well, it probably will make little difference in Wesnoth, yeah. 20161008 22:18:36< vultraz> hm, wait 20161008 22:18:38< vultraz> you're right 20161008 22:19:13< vultraz> windows uses case-insensitive sorting, so you're right. 20161008 22:19:14< celticminstrel> I mean, it's not all that likely that there will be a list of strings with weird casing. 20161008 22:19:43< gfgtdf> i acree that case insisiive ordering is mcuh better, it took me a year before a saw that the mp userlist n 1.12 is actually ordered case sensitive (i always thought it was just strange order like in 'more active player first') 20161008 22:19:46< tad_> Ya know .. if you want a REAL headache you should try slogging through the collation rules in the Unicode standard some time. 20161008 22:20:07< vultraz> oh god no :| 20161008 22:20:40< vultraz> (curious, though, do they sort emojis? :P ) 20161008 22:20:54< celticminstrel> Probably? 20161008 22:21:05< vultraz> oh god I'd love to see that meeting 20161008 22:21:07< tad_> Of course. But they fall to the "binary codepoint order" last-case rule. 20161008 22:21:24< vultraz> "Should the smiley come before the frown?" 20161008 22:21:59< celticminstrel> It would probably just sort in whatever order the code points happened to be placed in the Unicode standard. 20161008 22:22:15< celticminstrel> Which is probably pretty arbitrary. I doubt people put a lot of thought into it. 20161008 22:22:32< vultraz> (I also wonder now if emojis would display in wesnoth) 20161008 22:22:38< tad_> More importantly should the LGBT couples come before or after the hertos ... no matter what they do someone is NOT going to be happy there. 20161008 22:22:46< celticminstrel> I doubt it. 20161008 22:22:50< vultraz> tad_: ahhh yes :D 20161008 22:22:52< celticminstrel> Lato probably doesn't support them. 20161008 22:23:37< vultraz> so how DO apps display them 20161008 22:23:50< tad_> And here I was thinking that we might want to do something about dynamic use of Noto as a fallback for unknown gylphs. When/if Klingon ever makes it in, I'm sure some UMC author is gonna want it. 20161008 22:24:31< celticminstrel> I don't think many apps use fonts for emoji. 20161008 22:24:38< vultraz> I see 20161008 22:24:44< celticminstrel> They instead substitute images for specific character sequences. 20161008 22:24:50< vultraz> I see 20161008 22:24:53< vultraz> makes sense 20161008 22:24:59< celticminstrel> eg, colon-open-paren is substituted with a smiley face. 20161008 22:25:04< tad_> celticminstrel, Well they've only been in Unicode for a short while. Ask again in a year or two 20161008 22:25:10< celticminstrel> Yeah. 20161008 22:26:12< vultraz> tad_: more sorting nightmares: should the women come before or after the men? should the black emojis appears before or after the white emojis? :P 20161008 22:26:49< tad_> vultraz, So we'll need a SJW preferences setting ... ;P 20161008 22:27:11< vultraz> should the black lesbian family come before or after the white gay family? :P 20161008 22:27:17< vultraz> indeed xD 20161008 22:27:31< zookeeper> gfgtdf, yes switching those two lines seems to have fixed it 20161008 22:27:48< tad_> Oh, thank the Gods. 20161008 22:40:04< vultraz> oh hey, there's ttree_view_node::add_sibling 20161008 22:40:10< vultraz> might be what I'm looking for 20161008 22:40:18< vultraz> for something 20161008 22:40:51< vultraz> celticminstrel: how do the tree walkers work again? 20161008 22:42:30< vultraz> celticminstrel: for the record, you should have implemented ttree_view_node::fold and unfold instead of rolling a custom impl for the gamestate inspector 20161008 22:45:15< vultraz> I might do that 20161008 22:45:19< vultraz> if I can figure out this walker.. 20161008 22:45:48< celticminstrel> I can't remember exactly. Try finding an example of where it's used? 20161008 22:46:25-!- irker559 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout] 20161008 22:55:24< vultraz> blah 20161008 22:55:28< vultraz> how to do this.. 20161008 22:56:31< vultraz> is it more efficient to iterate over the tree, or the side_engines.. 20161008 22:57:26< vultraz> perhaps.. 20161008 22:57:34< vultraz> well, might have to use the latter 20161008 22:57:51< vultraz> since the tree has no knowledge of the sides it displays.. 20161008 22:58:10< vultraz> but then how does one find what node is attached to which side... 20161008 22:58:30< tad_> gfgtdf, Generally searching about discussions having to do with Lua and strcoll I came across two more locale issues in Lua. lua_str2number uses strtod() and the lexer uses the locale radixpoint as well as ',' when parsing numbers. I'm adding them to my list of things to consider when upgrading. 20161008 23:00:01< vultraz> celticminstrel: btw, I think jyrki's change to the listbox made it so an initially selected item isn't displayed.. 20161008 23:02:14< celticminstrel> That seems vaguely unlikely? 20161008 23:02:33< celticminstrel> But I dunno, maybe. 20161008 23:02:44< vultraz> er 20161008 23:02:48< vultraz> let me reword that 20161008 23:02:50< vultraz> scrolled to 20161008 23:03:03< vultraz> in mp create, the saved selection is selected but not scrolled to 20161008 23:10:21-!- Bonobo [~Bonobo@2001:44b8:254:3200:25f7:1b04:4a29:56a9] has joined #wesnoth-dev 20161008 23:13:40 * tad_ chuckles. Android does not support strcoll. The Android library uses a strcoll->strcmp thunk. 20161008 23:42:09 * celticminstrel notes that your rewording does not change my response. 20161008 23:42:39< tad_> ? 20161008 23:43:06< vultraz> ah 20161008 23:43:21< vultraz> well, it seems most likely 20161008 23:48:07< vultraz> ahh, add_sibling is exactly what I needed to put a line at the end 20161008 23:48:32< vultraz> always so nice when you realize an API has a little-known feature that does exactly what you need --- Log closed Sun Oct 09 00:00:59 2016