--- Log opened Sat Nov 26 00:00:33 2016
20161126 00:02:38-!- Bonobo [~Bonobo@2001:44b8:254:3200:8819:35f6:1512:efb8] has joined #wesnoth-dev
20161126 00:04:13< gfgtdf> vultraz: its quite possible that want just 'not reselecting' but rather 'selecteding the wrong unit becase the dislog get confuded by leaders with filter_recall' if the leader cannot recally all of the avaiable units
20161126 00:04:24< gfgtdf> wasn't*
20161126 00:04:48< vultraz> oh?
20161126 00:04:50< vultraz> hm...
20161126 00:04:55< vultraz> maybe i should test again..
20161126 00:05:01< gfgtdf> vultraz: in particular both bugreports were about LoW, and LoW is afaik the only mainly campaign that used filter_recall (a elst in 1.12)
20161126 00:05:24< gfgtdf> vultraz: that's why i think its related to filter_recall
20161126 00:05:27< vultraz> let me try again///
20161126 00:07:07< vultraz> tested with the attached save, everything works fine
20161126 00:07:11< vultraz> when dismissing
20161126 00:07:32< vultraz> (well, the sidebar unit displays fine at least)
20161126 00:10:03< gfgtdf> github now allows squashing all commits in a pr right ?
20161126 00:10:18< celticminstrel> gfgtdf: Yes, why?
20161126 00:10:42< gfgtdf> so i can make multiple-file commits on github with that.
20161126 00:11:07< celticminstrel> True.
20161126 00:11:17-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20161126 00:11:24< celticminstrel> I wouldn't really recommend it, but it is possible.
20161126 00:12:02< irker827> wesnoth: gfgtdf wesnoth:dontshowmpwaitstarted 8990eb6e5a46 / src/gui/dialogs/multiplayer/mp_join_game.hpp: Update mp_join_game.hpp https://github.com/wesnoth/wesnoth/commit/8990eb6e5a461a8b8ed4b5a041339023d56413ac
20161126 00:12:43< celticminstrel> What a terrible commit message.
20161126 00:12:53< matthiaskrgr> lol
20161126 00:12:57< celticminstrel> Ah, I see, you're planning to squash.3
20161126 00:15:11< irker827> wesnoth: gfgtdf wesnoth:dontshowmpwaitstarted aa0d9d36e3df / src/game_initialization/multiplayer.cpp: don't show mp join dialog when the game has already started https://github.com/wesnoth/wesnoth/commit/aa0d9d36e3dfa307081d70d9765dd97876ce5c11
20161126 00:15:26< gfgtdf> lets wait for travis.
20161126 00:15:57< celticminstrel> gfgtdf: In that case, I suggest next time putting [ci skip] in all but the final commit.
20161126 00:16:47< gfgtdf> celticminstrel: i think i did that? (unless i decide to add more commits later)
20161126 00:17:11< celticminstrel> So you did. Sorry, I spoke without looking first.
20161126 00:34:02< vultraz> ok, let' seee...
20161126 00:34:13< vultraz> we have a SDL_Color-like struct
20161126 00:34:17< vultraz> what conversion functions will we need
20161126 00:34:26< vultraz> I already have to_uint32
20161126 00:34:31< vultraz> to_pango_markup
20161126 00:34:32< vultraz> what else..
20161126 00:35:43< celticminstrel> to_sdl_color?
20161126 00:35:56< celticminstrel> Or maybe just to_sdl
20161126 00:35:58< vultraz> well, we might not be using SDL_Color...
20161126 00:36:04< vultraz> but i can add it
20161126 00:36:31< celticminstrel> Well, you might need it if passing to SDL routines.
20161126 00:38:07< vultraz> true, true
20161126 00:40:52-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20161126 00:48:43-!- Appleman1234_ [~Appleman1@KD106161196188.au-net.ne.jp] has joined #wesnoth-dev
20161126 00:50:01-!- Appleman1234 [~Appleman1@KD106161206045.au-net.ne.jp] has quit [Ping timeout: 250 seconds]
20161126 00:50:10-!- Appleman1234_ is now known as Appleman1234
20161126 00:52:05< gfgtdf> why woudl you need to_uint32 ?
20161126 00:52:23< irker827> wesnoth: Charles Dang wesnoth:master 493bd936b680 / / (5 files in 3 dirs): Added initial implementation of color_t wrapper class https://github.com/wesnoth/wesnoth/commit/493bd936b6803f54643c6a1c19ed2490eb47cee4
20161126 00:52:41< vultraz> Aginor, celticminstrel ^ do look over before i start making use of it
20161126 00:53:23< vultraz> gfgtdf: convenience 
20161126 00:53:39< gfgtdf> vultraz: ? please give usecases
20161126 00:55:05< vultraz> gfgtdf: some sdl functions expect Uint32
20161126 00:56:43< gfgtdf> vultraz: hmm ok
20161126 00:56:48< gfgtdf> vultraz: can you give an example ?
20161126 00:57:21< vultraz> hm..
20161126 00:57:26< vultraz> actually, can't think of any right now
20161126 00:57:27< gfgtdf> vultraz: those 1-argument constructors shoudl ba marked explicit
20161126 00:57:33< gfgtdf> be*
20161126 00:57:35< vultraz> oh right
20161126 00:58:23< vultraz> (not the default ctor?)
20161126 00:58:46< celticminstrel> vultraz: explicit is only needed for constructors that can be called with one argument.
20161126 00:58:55< vultraz> ok, only 1
20161126 00:58:58< gfgtdf> vultraz: the default constructor shodul have 0 arguments
20161126 00:59:42< celticminstrel> vultraz: That means: constructors that have exactly one argument; constructors that have one required argument and the rest are optional (ie with defaults); and constructors who have only optional arguments.
20161126 01:01:10< vultraz> now what is this "static factory" business?
20161126 01:01:50< gfgtdf> i perosnally woudl mostlikeley put the to_sdl and some of the ctors definitions in the header so the compiler can inline them more easily, not sure though.
20161126 01:02:51< vultraz> i wonder if any of these can be constexpr
20161126 01:03:44< gfgtdf> vultraz: i think they can but note sure of all our suported compliler do support constexpr in that way
20161126 01:03:50< gfgtdf> s/of/if
20161126 01:03:52< celticminstrel> vultraz: They probably can, though keep in mind we can't rely on constexpr due to MSVC 2013.
20161126 01:03:59< vultraz> CONSTEXPR?
20161126 01:04:11< celticminstrel> It works but may not have the same semantics.
20161126 01:04:46< celticminstrel> ie, it'll work on the declaration, but may not enable the additional uses that true constexpr would.
20161126 01:05:11< celticminstrel> So anyway I think I've run out of things to say on that commit. I answered your question inline.
20161126 01:06:21< vultraz> I assume if i constexpr stuff everything needs to be in the header?
20161126 01:07:32< celticminstrel> No idea.
20161126 01:07:47< celticminstrel> I don't think it matters whether everything is in the header.
20161126 01:07:50< vultraz> celticminstrel: why do you recommend a static function for uint32 only?
20161126 01:07:54< celticminstrel> I personally probably would, though.
20161126 01:08:08< celticminstrel> vultraz: Because that way the representation of the unit32 is unambiguous.
20161126 01:08:21< celticminstrel> ^uint
20161126 01:08:26< vultraz> wouldn't that mean I'd need to do color_t = color_r::from_rgba(uint32_var);?
20161126 01:08:45< vultraz> instead of color_t c (uint32_var)?
20161126 01:08:58< celticminstrel> Yes, but that's a good thing.
20161126 01:09:01< vultraz> ok
20161126 01:09:05< celticminstrel> It documents that you're expecting it to be rgba.
20161126 01:09:28< vultraz> ok
20161126 01:09:28< celticminstrel> So if someone realizes that argb or bgra or something was passed, they can see what the problem is more easily.
20161126 01:09:35< vultraz> [12:07:53]	celticminstrel	I personally probably would, though.
20161126 01:09:44< vultraz> are you saying you would personally have evertyhing in the header?
20161126 01:09:46< vultraz> everything
20161126 01:10:09< celticminstrel> Possibly. Not sure.
20161126 01:10:30< celticminstrel> The stream one, probably not.
20161126 01:10:38< celticminstrel> ie, to_pango_markup
20161126 01:10:50< celticminstrel> The non-string constructors, definitely.
20161126 01:10:54< celticminstrel> Not sure on the string constructor.
20161126 01:11:11< celticminstrel> But my personal choice may not always be "best practice". :P
20161126 01:11:34< vultraz> I forgot, do static member functions need to be implemented in the header?
20161126 01:11:42< celticminstrel> No.
20161126 01:11:49< vultraz> 'k
20161126 01:13:52< gfgtdf> vultraz: it'd also put the string ctor in a static function, mainly becasue that way you can give hem differnt names for each string format.
20161126 01:14:29< celticminstrel> I guess you have a point there.
20161126 01:14:40< celticminstrel> from_rgb_triple
20161126 01:14:52< celticminstrel> from_pango_hex
20161126 01:14:56< celticminstrel> etc
20161126 01:18:30< vultraz> tru tru tru
20161126 01:26:10-!- travis-ci [~travis-ci@ec2-54-242-240-19.compute-1.amazonaws.com] has joined #wesnoth-dev
20161126 01:26:10< travis-ci> wesnoth/wesnoth#12162 (dontshowmpwaitstarted - aa0d9d3 : gfgtdf): The build has errored.
20161126 01:26:11< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/178969458
20161126 01:26:11-!- travis-ci [~travis-ci@ec2-54-242-240-19.compute-1.amazonaws.com] has left #wesnoth-dev []
20161126 01:35:16-!- RatArmy [~RatArmy@133.15.175.65] has joined #wesnoth-dev
20161126 01:38:32< irker827> wesnoth: Charles Dang wesnoth:master dfc23c3b8801 / src/sdl/ (color.cpp color.hpp): Address feedback https://github.com/wesnoth/wesnoth/commit/dfc23c3b8801b9120f7545bb4737d02d6e2f27d0
20161126 01:38:34< vultraz> celticminstrel, Aginor ^
20161126 01:40:33< vultraz> er, I seem to have messed something up..
20161126 01:40:43< vultraz> oh, nvm
20161126 01:40:46< vultraz> one is in the header
20161126 01:43:13< celticminstrel> (Just to be sure I didn't mess up... invalid_argument is thrown by stoul, right?)
20161126 01:43:35< vultraz> i didn't check
20161126 01:43:41< vultraz> i took your word for it :/
20161126 01:43:46-!- Greg-Boggs [~greg_bogg@c-76-115-139-154.hsd1.or.comcast.net] has joined #wesnoth-dev
20161126 01:43:59< celticminstrel> I should've checked. >_>
20161126 01:44:32< celticminstrel> Phew, I was right.
20161126 01:45:02< celticminstrel> It also throws out_of_range if the value is greater than 2^32 (or possibly 2^64) minus 1.
20161126 01:45:22< celticminstrel> IOW if you have more than ... I think... 10 digits?
20161126 01:45:28< celticminstrel> Something like that.
20161126 01:47:43-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev
20161126 02:01:35-!- Greg-Boggs [~greg_bogg@c-76-115-139-154.hsd1.or.comcast.net] has quit [Remote host closed the connection]
20161126 02:11:46-!- gfgtdf_ [~chatzilla@x4e369bba.dyn.telefonica.de] has joined #wesnoth-dev
20161126 02:14:46-!- gfgtdf [~chatzilla@x4e363f60.dyn.telefonica.de] has quit [Ping timeout: 252 seconds]
20161126 02:14:55-!- gfgtdf_ is now known as gfgtdf
20161126 02:18:40< vultraz> celticminstrel: so, nothing more to add?
20161126 02:19:25< celticminstrel> Guess not.
20161126 02:20:01< celticminstrel> Not entirely happy with from_rgba_uint32, I guess. But that's a pretty minor thing.
20161126 02:20:11< vultraz> hm?
20161126 02:20:22< celticminstrel> Also the fact that the string one allows alpha.
20161126 02:20:34< celticminstrel> I'm just talking about the name there.
20161126 02:20:48-!- travis-ci [~travis-ci@ec2-54-159-132-187.compute-1.amazonaws.com] has joined #wesnoth-dev
20161126 02:20:49< travis-ci> wesnoth/wesnoth#12163 (master - 493bd93 : Charles Dang): The build has errored.
20161126 02:20:49< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/178972841
20161126 02:20:49-!- travis-ci [~travis-ci@ec2-54-159-132-187.compute-1.amazonaws.com] has left #wesnoth-dev []
20161126 02:21:06< vultraz> what would you name it
20161126 02:21:23< celticminstrel> I think from_rgb_string (no alpha) is better. And for the integer, maybe from_rgba_bytes, but I'm not really sure if that's better.
20161126 02:21:47< vultraz> ... but it does accept alpha
20161126 02:21:47< celticminstrel> Though I understand that some places might need to support strings that include alpha.
20161126 02:21:51< vultraz> and it should accept alpha
20161126 02:22:03< celticminstrel> No, that's what I'm saying. I disagree, it shouldn't accept alpha.
20161126 02:22:15< vultraz> I could add a non-alpha version
20161126 02:22:59< celticminstrel> I'm actually curious, where are four-element strings of that kind accepted?
20161126 02:23:04< celticminstrel> ie, r,g,b,a strings.
20161126 02:23:14< vultraz> ...gui2!
20161126 02:23:47< celticminstrel> And what would be the price of dropping that?
20161126 02:23:53< vultraz> uh
20161126 02:23:54< vultraz> huge?
20161126 02:24:19< celticminstrel> Anyway, if there's a separate from_rgb_string we can at least ensure that any non-GUI2 WML cases use that.
20161126 02:24:26< celticminstrel> So I guess that'd be helpful to have.
20161126 02:25:00< celticminstrel> Non-GUI2 WML generally has alpha as a separate key, which IMO makes more sense.
20161126 02:25:07< vultraz> ...why!
20161126 02:25:22< vultraz> i don't even know of a case *with* an alpha key :|
20161126 02:25:26< celticminstrel> Because opacity isn't really part of the colour most of the time.
20161126 02:25:41< celticminstrel> Animations have an alpha key IIRC. Some places have an opacity key, I think.
20161126 02:25:42< vultraz> show me a tag with an opacity setting.
20161126 02:29:01< vultraz> animations have it
20161126 02:29:05< vultraz> but that's something different
20161126 02:29:07< vultraz> not color
20161126 02:41:06< EliDupree> Wesnoth.simulate_combat is network-unsafe, right? It should probably be marked as such on the wiki
20161126 02:43:51< gfgtdf> EliDupree: not sure, but since it was mostly written for ai code it likeley is
20161126 02:46:21-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20161126 02:46:40< gfgtdf> celticminstrel: i thinp p ango also allows #rrggbbaa format somwhere.
20161126 02:48:07< celticminstrel> :(
20161126 02:48:10< EliDupree> I'm using it in a synchronize_choice right now, but I'm probably going to have to abandon it because I have a scenario where it would get used like hundreds of times per turn, so the network roundtrips are too costly. I guess I could pack all of the results into a single synchronize_choice, but then I would have to convert them into WML tables, which is annoying. And I'm not sure doing a full simulation was what I wanted in the first 
20161126 02:48:10< EliDupree> place
20161126 02:49:11 * celticminstrel would expect simulate_combat to be network-safe, but maybe it desyncs the RNG or something.
20161126 02:49:17-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20161126 02:49:30< EliDupree> celticminstrel: @#$%ing floating points, buddy
20161126 02:49:31< gfgtdf> celticminstrel: quite sure it doesnt desnc  the rng
20161126 02:51:15< vultraz> hmm
20161126 02:51:29-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20161126 02:51:34< vultraz> im thinking color_t::to_pango_markup should actually be to_hex_string
20161126 02:51:40< vultraz> and the '#' added by span_color
20161126 02:51:49< vultraz> since that's formatting
20161126 02:51:56< vultraz> and formatting should not be handled by this class
20161126 02:52:08< gfgtdf> floating points are quitte annoying, in 1.12 even code like [gold] amount=0.5 [/gold](or something more realstic "wesnoth.wml_actions.gold { amount = 100 /n_players}" ) can cause OOS.
20161126 02:52:21< vultraz> gfgtdf: ...why
20161126 02:53:21< gfgtdf> vultraz: becasue it was rounded diffently on different compliers/plattofmrs.
20161126 02:53:37< vultraz> blagh
20161126 02:54:04< vultraz> this is why a central server design is better >_>
20161126 02:55:28< vultraz> (ie, send the result, not the code)
20161126 02:57:39< gfgtdf> well this bug was fixed with lua 5.3 upgrade afaik.
20161126 03:00:35< vultraz> why the hell does std::strtol need a second and third argument :|
20161126 03:03:34< irker827> wesnoth: Charles Dang wesnoth:master 6ac771551c01 / src/sdl/ (color.cpp color.hpp): Made to_pango_markup return the hex color only (no #) and added from_hex_string https://github.com/wesnoth/wesnoth/commit/6ac771551c01934fdb8309b5a5f0d4df0da39f87
20161126 03:03:44< vultraz> for the record I haven't tested any of this :P
20161126 03:03:53< vultraz> it could return All The Wrong Things
20161126 03:04:10< celticminstrel> What's with the :| comment
20161126 03:04:27< vultraz> char is too C for my taste 
20161126 03:04:39< gfgtdf> vultraz: std::strtol is the same as standard c strtol 
20161126 03:04:40< celticminstrel> I'm pretty sure strol is a C function.
20161126 03:04:48< celticminstrel> C99 possibly?
20161126 03:05:12< vultraz> could I use lexical_cast instead?
20161126 03:05:18< celticminstrel> Also, "char" isn't C at all. Don't get it confused with "char*".
20161126 03:05:29< vultraz> eh?
20161126 03:05:35< vultraz> what's the difference
20161126 03:05:41< celticminstrel> "char" is a single character.
20161126 03:05:55< celticminstrel> (Okay, yes, it's C, but there's nothing about it that makes it more C than C++.)
20161126 03:06:23< gfgtdf> vultraz: also in from_hex_string you shoudl cache the result of strtol and not call it 3 times with the same arameters
20161126 03:06:33< vultraz> hm, yes
20161126 03:06:40< vultraz> (still, can I use lexical_cast?)
20161126 03:07:04< vultraz> google, I must consult..
20161126 03:07:17< celticminstrel> I guess the static_cast to uint8_t (which, BTW, is probably a typedef of unsigned char :P ) truncates the extra high bits...
20161126 03:07:19< gfgtdf> vultraz: also you can afaik also just pass nullptr as second argument.
20161126 03:07:24< celticminstrel> lexical_cast shouldn't work there.
20161126 03:10:00< vultraz> ah nullptr works
20161126 03:11:44< gfgtdf> vultraz: did you test from_rgba_uint32 ?
20161126 03:11:54< vultraz> [14:03:42]	vultraz	for the record I haven't tested any of this
20161126 03:12:42< vultraz> nor do i have a really good test case for everything
20161126 03:12:53< celticminstrel> vultraz: You could add a new unit test?
20161126 03:12:53< gfgtdf> vultraz: it looks wrong, i'D expect that te value filtered with for example SDL_BLUE_MASK  is then shifted with SDL_BLUE_BITSHIFT instead its shifted with 8
20161126 03:13:15< vultraz> celticminstrel: how? and wouldn't I need to see the color?
20161126 03:13:29< celticminstrel> What?
20161126 03:13:37< celticminstrel> Why would you need to see the colour?
20161126 03:13:43< vultraz> eh, good point
20161126 03:13:53< vultraz> gfgtdf: Aginor's bitshifts assume ARGB
20161126 03:13:53< celticminstrel> I'm just talking about verifying the reversibility of the conversions, really.
20161126 03:14:03< celticminstrel> Do they?
20161126 03:14:06< vultraz> yes
20161126 03:14:09< vultraz> no idea why
20161126 03:14:17< celticminstrel> There's probably a good reason.
20161126 03:14:19< vultraz> anyway, I don't know how to make a unit test
20161126 03:14:27< gfgtdf> vultraz: Aginors bitshits assume the say thigns as his MASKs
20161126 03:14:40< gfgtdf> vultraz: so egher the maks or the shift is wrong
20161126 03:14:45< vultraz> hm
20161126 03:14:57< vultraz> but isn't 0x00FF0000 regardless of ARGB or RGBA?
20161126 03:15:01< vultraz> red regardless*
20161126 03:15:02< celticminstrel> No.
20161126 03:15:23< gfgtdf> vultraz: assumng you use Aignors shifts, from_hex_string can likely  be simplfied to from_hex_string(string c) { return from_rgba_uint32(std::strtol(c.c_str(), nullptr, 16)); }
20161126 03:15:24< vultraz> dammit
20161126 03:15:34< celticminstrel> It'd be green in RGBA I think.
20161126 03:15:55< celticminstrel> But, uhh.
20161126 03:16:00< gfgtdf> hmm wait, not sure how that woudl do to the apha key
20161126 03:16:03< celticminstrel> Don't we want ARGB anyway?
20161126 03:16:08< vultraz> no!
20161126 03:16:12< celticminstrel> Or is there some specific reason to want RGBA?
20161126 03:16:13< vultraz> well..
20161126 03:16:22< celticminstrel> Like, eg, "pango assumes RGBA".
20161126 03:16:33< vultraz> pango assumes nothing because it uses hex
20161126 03:16:41< celticminstrel> What's that supposed to mean?
20161126 03:16:57< vultraz> pango markup has no alpha component
20161126 03:17:12< gfgtdf> vultraz: pango also supports apha in someplaced
20161126 03:17:20 * vultraz throws up hands
20161126 03:17:22< celticminstrel> The real question is, where we're using uint32's as colours, is it RGBA or ARGB?
20161126 03:17:31< vultraz> I'm assuming RGBA
20161126 03:17:33< vultraz> everywhere
20161126 03:17:36< celticminstrel> Should probably answer that question before fixing the function.
20161126 03:18:03< vultraz> it makes more sense
20161126 03:18:06< gfgtdf> vultraz: iirc foreground #rrggbbaa is possible.
20161126 03:18:07< celticminstrel> I disagree.
20161126 03:18:14< celticminstrel> ARGB makes more sense.
20161126 03:18:19< vultraz> especially since GUI2 uses R G B A formatting
20161126 03:18:23< gfgtdf> in pango amrkup
20161126 03:18:25< celticminstrel> With 0 for opaque.
20161126 03:18:30< vultraz> ....
20161126 03:18:34< vultraz> 0 is transparent!
20161126 03:18:35< celticminstrel> The formatting that GUI uses is irrelevant.
20161126 03:18:50< celticminstrel> But if you're using ints as numbers, ARGB with 0 opaque is the most sensible.
20161126 03:18:54< vultraz> no, it's very relevant, since the bitshifts have to match
20161126 03:19:07< celticminstrel> No they don't? GUI2 is representing them as strings, right?
20161126 03:19:12< gfgtdf> the app panog c++ api afaik just uses 4 parmaeters for functions that take colors
20161126 03:19:15< celticminstrel> Because, statistically speaking, most of your colours are opaque.
20161126 03:19:26< vultraz> ah, true
20161126 03:19:41< celticminstrel> So, if you use ARGB with 0 opaque, you can write colours in the code as eg 0xFFEEDD.
20161126 03:19:52< vultraz> but seriously, where the hell do you get 0 for opaque 
20161126 03:19:54< vultraz> that makes no sense
20161126 03:19:57< celticminstrel> I'm not recommending we use ARGB with 0 opaque, just pointing out a reason why it's more sensible.
20161126 03:20:03< celticminstrel> In certain situations.
20161126 03:20:05< vultraz> 1 is allmmosttt transparent... and then 0 is opaque?
20161126 03:20:09< vultraz> what kind of scale is that
20161126 03:20:22< celticminstrel> No, I'm talking about a reversed scale, so 255 would be transparent.
20161126 03:20:34< vultraz> oh, ok
20161126 03:20:37< vultraz> that makes a little more sense
20161126 03:20:53< vultraz> but anyway, SDL uses 255 for opaque
20161126 03:21:05< vultraz> they switched back in 1.2.something, so we'll stick with that.
20161126 03:21:17< celticminstrel> See, if you're hard-coding colours in code as integers, most of the colours should be opaque, so by making 0 alpha represent opaque and using ARGB, it means you don't need to specify the alpha for every single one of those colours.
20161126 03:21:29< celticminstrel> It's an argument that (hopefully) doesn't apply to Wesnoth.
20161126 03:22:15< celticminstrel> It might be one of the reasons that ARGB with 0 opaque exists, though.
20161126 03:22:28< vultraz> ..eh?
20161126 03:22:37< celticminstrel> Anyway, the question is whether we currently use ints as ARGB or RGBA, and Aginor's masks/shifts suggest the former.
20161126 03:22:48< vultraz> oh
20161126 03:22:49< vultraz> hm
20161126 03:22:52< celticminstrel> What're you confused about now?
20161126 03:22:57< vultraz> i just realized that technically
20161126 03:23:06< vultraz> well
20161126 03:23:08< vultraz> is it so?
20161126 03:23:11< celticminstrel> ???
20161126 03:23:25< vultraz> that each of the R G B components has its own opaque alpha?
20161126 03:23:39< celticminstrel> ???
20161126 03:23:55< vultraz> blagh
20161126 03:23:57< vultraz> nvm
20161126 03:24:54< vultraz> what do you mean by "it means you don't need to specify the alpha for every single one of those colours."
20161126 03:24:59-!- gfgtdf [~chatzilla@x4e369bba.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.93 [Firefox 50.0/20161104212021]]
20161126 03:25:52< celticminstrel> If you're writing out the colours as ints in your code, then you would use the C hex notation, 0xabcdef
20161126 03:26:37-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev
20161126 03:26:39< celticminstrel> Assuming ARGB, the "ef" is blue, "cd" is green, "ab" is red, and the omitted digits "00" to the left of that are the alpha.
20161126 03:26:45< celticminstrel> ancestral: Hi
20161126 03:26:50< ancestral> Hi
20161126 03:26:53< celticminstrel> Any chance of updating the XCode project?
20161126 03:27:06< celticminstrel> I'll definitely get to it eventually if not.
20161126 03:28:06< celticminstrel> vultraz: If 0 means opaque, you can just write all your colours like that. If instead "ff" is opaque, you'd always need to write eg 0xffabcdef.
20161126 03:29:00< vultraz> what is 'ff'
20161126 03:29:07< celticminstrel> 255 in hex?.
20161126 03:29:13< vultraz> oh
20161126 03:29:33< vultraz> so that's what that 00 means
20161126 03:29:38< vultraz> i assumed it was random noise 
20161126 03:29:52< celticminstrel> You mean where I siad "00 to the left ..."?
20161126 03:29:55< vultraz> or that 0x00 was some sort of formatting
20161126 03:30:08< vultraz> ie, [0x00]thecolorhere
20161126 03:30:42< celticminstrel> Well you could write 0x00abcdef if you wanted to.
20161126 03:30:42< vultraz> (doesn't 0x00 mean something else tho?)
20161126 03:30:46< celticminstrel> No?
20161126 03:30:51< ancestral> celticminstrel: Yeah, I have the libs
20161126 03:30:56< celticminstrel> What else would it mean?
20161126 03:31:08< celticminstrel> ancestral: I was more thinking about adding new files to it.
20161126 03:31:15< celticminstrel> ancestral: But a libs update would be great too.
20161126 03:31:21< ancestral> Oh the project file, right
20161126 03:31:33< celticminstrel> I had to help someone get around that not long ago.
20161126 03:31:41< ancestral> Gotcha
20161126 03:31:58< ancestral> By Tuesday night I’ll see what I can do
20161126 03:32:03< celticminstrel> The libs I mean, not the out-of-date project. (I think that was just before I last updated it.)
20161126 03:34:57< vultraz> suddenly everything became more complicated :|
20161126 03:36:00 * vultraz yells into the distance for Aginor
20161126 03:37:06< celticminstrel> Anyway, the choice of ARGB vs RGBA for the unit32_t shouldn't really depend on the fact that GUI2 uses r,g,b,a.
20161126 03:37:12< celticminstrel> ^uint
20161126 03:38:11< vultraz> yes, that's true
20161126 03:38:26< vultraz> as long as alpha is arg 4
20161126 03:41:47< irker827> wesnoth: Charles Dang wesnoth:master 15a11796c779 / src/sdl/color.cpp: Small fixup 6ac771551c01 https://github.com/wesnoth/wesnoth/commit/15a11796c779d5e774324698a3017daeb5d0fe4f
20161126 04:10:31< vultraz> blagh
20161126 04:10:36< vultraz> 26 cases of snprintf in the code :|
20161126 04:10:56< vultraz> there were only 2 cases of sprintf and i removed those, but it seems snprintf is numerous 
20161126 04:12:30< vultraz> im not going  to do more with color.*pp until i talk to Aginor 
20161126 04:12:32< celticminstrel> Well, that's good. sprintf is dangerous, but snprintf is the "safe" version.
20161126 04:12:53< celticminstrel> Mind you, it's still very C.
20161126 04:13:01< vultraz> down with C!
20161126 04:49:33< vultraz> text_color = display::rgb(cfg["red"], cfg["green"], cfg["blue"]);
20161126 04:49:37< vultraz> hmmm
20161126 04:49:58 * vultraz groans
20161126 04:50:28< vultraz> color util functions in display.hp :|
20161126 04:50:48-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20161126 04:52:06< vultraz> 	static Uint32 rgb(Uint8 red, Uint8 green, Uint8 blue)
20161126 04:52:07< vultraz> 		{ return 0xFF000000 | (red << 16) | (green << 8) | blue; }
20161126 04:52:25< vultraz> how is this different from (color.r << 16 ) + (color.g << 8) + (color.b)
20161126 04:52:47< vultraz> ie, why | and not +
20161126 04:55:37< vultraz> gah
20161126 04:55:43< vultraz> looks like more crap to deal with later
20161126 04:55:51< vultraz> really need to talk to Aginor 
20161126 05:03:28< vultraz> I wonder if i should make operator== a struct member or not..
20161126 05:05:50-!- RatArmy [~RatArmy@133.15.175.65] has quit [Quit: Konversation terminated!]
20161126 05:10:15-!- Jetrel_bot [~Jetrel@ec2.happyspork.com] has quit [Ping timeout: 244 seconds]
20161126 05:10:28-!- Jetrel_bot [~Jetrel@ec2.happyspork.com] has joined #wesnoth-dev
20161126 05:10:52< celticminstrel> vultraz: | can be thought of as "add ignoring carry" and is the correct way to do it in this case, since a carry would interfere with the adjacent field.
20161126 05:11:10< vultraz> wait, I'm not supposed to use +?
20161126 05:11:14< celticminstrel> No.
20161126 05:11:26< vultraz> fuck
20161126 05:11:28< celticminstrel> You were using + ? Sorry I didn't notice...
20161126 05:11:33< vultraz> yes :|
20161126 05:11:48< vultraz> in color2hexa too
20161126 05:11:56< celticminstrel> It probably won't cause problems when parsing from a string.
20161126 05:12:18< celticminstrel> Since by the nature of the process, the components are in a form such that no carry is generated while adding.
20161126 05:12:31-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev
20161126 05:12:32< celticminstrel> Still good practice though.
20161126 05:14:15 * celticminstrel notes that this is ignoring carry in the binary representation, so it's not the same result as adding decimal numbers without carry.
20161126 05:14:28 * vultraz curses whoever created a separate color struct for ToDs :|
20161126 05:14:40< celticminstrel> Feel free to delete it? :P
20161126 05:15:05< vultraz> I have to change a bunch of code to do so
20161126 05:15:12< vultraz> including display.hpp :|
20161126 05:15:28< celticminstrel> Code that should be changed anyway, right?
20161126 05:15:30< vultraz> using SDL_Color for now until Aginor greenlights color_t
20161126 05:16:05< celticminstrel> Well, moving SDL_Color to color_t should be quite a bit easier than switching from uint32 and whatever else to SDL_Color.
20161126 05:16:30< celticminstrel> Though it's still preferable to do it all in one step.
20161126 05:17:35< vultraz> display.hpp should not ()*@)(#*() affect so much stuff
20161126 05:20:28< vultraz> i wonder if I need to_rgba_string..
20161126 05:21:18< vultraz> ugh
20161126 05:21:29< vultraz> i guess part of the appeal of this struct was its operators
20161126 05:21:42< vultraz> tod_color col = color_adjust_ + tod.color;
20161126 05:21:43< vultraz> etc
20161126 05:31:25-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:ad9e:9fc1:fc47:250a] has joined #wesnoth-dev
20161126 06:07:20-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:ad9e:9fc1:fc47:250a] has quit [Remote host closed the connection]
20161126 06:11:50-!- Kwandulin [~Miranda@p200300760F6EBFED0D6FE93BEB660C9B.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161126 06:18:56-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20161126 06:32:27-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20161126 06:41:58-!- irker827 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20161126 07:14:57-!- Kwandulin [~Miranda@p200300760F6EBFED0D6FE93BEB660C9B.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds]
20161126 07:35:28-!- Kwandulin [~Miranda@p200300760F6EBFED0D6FE93BEB660C9B.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161126 08:04:48-!- JyrkiVesterinen [~JyrkiVest@87-100-211-239.bb.dnainternet.fi] has joined #wesnoth-dev
20161126 08:14:36< JyrkiVesterinen> 20161125 23:30:50< vultraz> i wish jyrki would use the standard if() format instead of if ()
20161126 08:14:36< JyrkiVesterinen> 20161125 23:30:57< vultraz> even if he puts { on a new line :/
20161126 08:14:58< JyrkiVesterinen> Fine, I can change my writing style. I had thought other developers don't care about that.
20161126 08:15:23< JyrkiVesterinen> I surrender in the Holy War of Brace Placement.
20161126 08:15:24< JyrkiVesterinen> http://mangafox.me/manga/iki_no_kore_shachiku_chan/v01/c005/4.html
20161126 08:15:58< JyrkiVesterinen> 20161125 23:35:49< gfgtdf> JyrkiVesterinen: i wondt think the server sends a [start_game] message, it just sends the scenario wml with started=yes
20161126 08:16:39< JyrkiVesterinen> No, it did send [start_game]. I checked that by adding an assertion to the loop in mp_join_game::fetch_game_config().
20161126 08:17:22< JyrkiVesterinen> 20161125 23:40:32< gfgtdf> JyrkiVesterinen: is there a reason why you check "started" at network_handler() instead of after fetch_game_config() is called ? (where the eother change in that commit was made?)
20161126 08:17:51< JyrkiVesterinen> Simply that I didn't think of the possibility to check it outside of the mp_join_game dialog itself.
20161126 08:18:52< JyrkiVesterinen> Your branch looks like a good idea. The test doesn't pass in that branch though.
20161126 08:19:24< JyrkiVesterinen> Maybe the test relies on something that mp_join_game::pre_show() does between scenarios?
20161126 08:22:00-!- Kwandulin [~Miranda@p200300760F6EBFED0D6FE93BEB660C9B.dip0.t-ipconnect.de] has quit [Ping timeout: 260 seconds]
20161126 08:23:03-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20161126 08:23:39-!- Kwandulin [~Miranda@p200300760F6EBFED0D6FE93BEB660C9B.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161126 08:29:26< JyrkiVesterinen> 20161126 02:49:11 * celticminstrel would expect simulate_combat to be network-safe, but maybe it desyncs the RNG or something.
20161126 08:29:55< JyrkiVesterinen> In Monte Carlo mode, the combat simulation code uses the default random number generator.
20161126 08:30:21< JyrkiVesterinen> The default RNG is documented as:
20161126 08:30:26< JyrkiVesterinen> "This generator is automatically synced during synced context.
20161126 08:30:26< JyrkiVesterinen> 		Calling this rng during a synced context automatically makes undoing impossible.
20161126 08:30:26< JyrkiVesterinen> 		Outside a synced context this has the same effect as rand()"
20161126 08:31:31< JyrkiVesterinen> I'm not sure about the details here, such as how much network traffic that generates or if it can result in RNG desync.
20161126 09:05:55-!- Kwandulin [~Miranda@p200300760F6EBFED0D6FE93BEB660C9B.dip0.t-ipconnect.de] has quit [Ping timeout: 256 seconds]
20161126 09:49:12< wedge009> JyrkiVesterinen: Don't worry, I picked up the habit of adding spaces before brackets from my first job. I find the extra spacing makes things easier to read.
20161126 09:50:46< JyrkiVesterinen> I mean that the only reason why I was adding spaces is that I thought others didn't care if I do that. It's not hard for me to follow either option.
20161126 09:58:10-!- Kwandulin [~Miranda@p200300760F6EBFED453A5D262F2C0A26.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161126 09:59:07-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20161126 09:59:26-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev
20161126 09:59:53-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Client Quit]
20161126 10:00:15-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev
20161126 10:00:15-!- mjs-de [~mjs-de@x4db56d82.dyn.telefonica.de] has joined #wesnoth-dev
20161126 10:00:40-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Client Quit]
20161126 10:01:05-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev
20161126 10:01:28-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Client Quit]
20161126 10:01:55-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev
20161126 10:02:18-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Client Quit]
20161126 10:02:43-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev
20161126 10:03:08-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Client Quit]
20161126 10:03:33-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev
20161126 10:03:55-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Client Quit]
20161126 10:04:18-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev
20161126 10:04:43-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Client Quit]
20161126 10:05:04-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev
20161126 10:05:31-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Client Quit]
20161126 10:12:31-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20161126 10:55:54-!- JyrkiVesterinen [~JyrkiVest@87-100-211-239.bb.dnainternet.fi] has quit [Quit: .]
20161126 11:21:01-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161126 11:22:56-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 268 seconds]
20161126 11:22:57-!- wedge010 is now known as wedge009
20161126 11:34:17-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20161126 12:01:24-!- irker852 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20161126 12:01:24< irker852> wesnoth: loonycyborg wesnoth:master 60329a87a125 / CMakeLists.txt SConstruct src/SConscript src/lua/SConscript: Rename Optimize build variant to Optimized for clarity https://github.com/wesnoth/wesnoth/commit/60329a87a1254be0231753ce4da213649736062e
20161126 12:07:55-!- astrelyon [~astrelyon@dh207-48-227.xnet.hr] has joined #wesnoth-dev
20161126 12:23:46-!- Kwandulin [~Miranda@p200300760F6EBFED453A5D262F2C0A26.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20161126 12:35:12< irker852> wesnoth: Wedge009 wesnoth:master be26cd3b2b97 / projectfiles/VC12/ (wesnoth.vcxproj wesnoth.vcxproj.filters): Updating VC project. https://github.com/wesnoth/wesnoth/commit/be26cd3b2b97fc57721f81a5a67ad3055b75bd80
20161126 12:46:29-!- atarocch [~atarocch@93.56.160.28] has quit [Ping timeout: 248 seconds]
20161126 12:49:57-!- atarocch [~atarocch@93.56.160.28] has joined #wesnoth-dev
20161126 12:55:40-!- Duthlet [~Duthlet@dslb-146-060-035-062.146.060.pools.vodafone-ip.de] has joined #wesnoth-dev
20161126 12:59:56-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20161126 13:00:03-!- atarocch [~atarocch@93.56.160.28] has quit [Ping timeout: 260 seconds]
20161126 13:01:28-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161126 13:03:30-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161126 13:04:38-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 245 seconds]
20161126 13:04:39-!- wedge010 is now known as wedge009
20161126 13:54:24< irker852> wesnoth: gfgtdf wesnoth:master 45ce94aae3e7 / data/multiplayer/scenarios/2p_Hornshark_Island.cfg: fix unit id conflict in 2p_Hornshark_Island.cfg https://github.com/wesnoth/wesnoth/commit/45ce94aae3e757a8a177fdcdc1d1e7f6a01fa189
20161126 14:05:53-!- gfgtdf [~chatzilla@x4e36a8ae.dyn.telefonica.de] has joined #wesnoth-dev
20161126 14:06:06-!- Kwandulin [~Miranda@p200300760F6EBFED093A106372B9BA0A.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161126 14:17:28-!- gfgtdf [~chatzilla@x4e36a8ae.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.93 [Firefox 50.0/20161104212021]]
20161126 14:31:52-!- Bonobo [~Bonobo@2001:44b8:254:3200:8819:35f6:1512:efb8] has quit [Ping timeout: 258 seconds]
20161126 14:48:53-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20161126 14:48:59-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20161126 15:05:37-!- atarocch [~atarocch@93.56.160.28] has joined #wesnoth-dev
20161126 15:49:33-!- DeFender1031 [~DeFender1@93-172-151-164.bb.netvision.net.il] has joined #wesnoth-dev
20161126 15:57:27-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20161126 15:57:33-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20161126 16:07:03-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20161126 16:07:09-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20161126 16:17:25-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20161126 16:45:44-!- JyrkiVesterinen [~JyrkiVest@87-100-193-182.bb.dnainternet.fi] has joined #wesnoth-dev
20161126 16:52:28-!- mjs-de [~mjs-de@x4db56d82.dyn.telefonica.de] has quit [Remote host closed the connection]
20161126 16:54:26-!- irker852 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20161126 17:21:58-!- ancestral [~ancestral@63.92.240.233] has joined #wesnoth-dev
20161126 17:29:03-!- Ravana_ [~Ravana@unaffiliated/ravana/x-2327071] has quit [Read error: Connection reset by peer]
20161126 17:34:23-!- Ravana_ [~Ravana@unaffiliated/ravana/x-2327071] has joined #wesnoth-dev
20161126 17:34:40-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20161126 17:36:48-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:ad9e:9fc1:fc47:250a] has joined #wesnoth-dev
20161126 17:39:11-!- gfgtdf [~chatzilla@x4e36a8ae.dyn.telefonica.de] has joined #wesnoth-dev
20161126 17:39:14< gfgtdf> 20161126 08:16:39< JyrkiVesterinen> No, it did send [start_game]. I checked that by adding an assertion to the loop in mp_join_game::fetch_game_config().
20161126 17:39:25< gfgtdf> JyrkiVesterinen: maby eit sends [start_game] before it sends the scnarios content ?
20161126 17:39:54-!- ancestral [~ancestral@63.92.240.233] has quit [Quit: i go nstuf kthxbai]
20161126 17:40:14< JyrkiVesterinen> From what I recall, the host sends [start_game] on its own. The guest requests the next scenario only after that.
20161126 17:41:00< JyrkiVesterinen> So it may well be that at the time the guest requests the scenario, the server has already sent [start_game] to it and can't exactly pull it back.
20161126 17:54:11-!- irker622 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20161126 17:54:12< irker622> wesnoth: gfgtdf wesnoth:dontshowmpwaitstarted 3266baa2d397 / src/game_initialization/playcampaign.cpp: temporarily debug info https://github.com/wesnoth/wesnoth/commit/3266baa2d39738885c816bd93a54d4f9ee44c1c4
20161126 17:56:31-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:ad9e:9fc1:fc47:250a] has quit [Remote host closed the connection]
20161126 18:00:19-!- Greg-Boggs [~greg_bogg@c-76-115-139-154.hsd1.or.comcast.net] has joined #wesnoth-dev
20161126 18:11:24-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20161126 18:11:30-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20161126 18:33:54< EliDupree> LOL, I thought I could optimize changing unit overlays by using [unit_overlay] and [remove_unit_overlay] directly, rather than using wesnoth.put_unit with the entire unit table (which is a little slow). But those tags are just implemented, in lua, using wesnoth.put_unit with unit tables!
20161126 18:35:47< vultraz> is that good or bad
20161126 18:36:07< EliDupree> Bad for me, at least
20161126 18:37:16< EliDupree> I want to be able to update a lot of units' overlays quickly, and even in 1.13 there isn't a way to do that through a lua proxy unit
20161126 18:37:41< vultraz> odd
20161126 18:37:47< celticminstrel> Then we should add that to the proxy unit...
20161126 18:37:54< vultraz> talk to celticminstrel, he probably has it as a planned feature
20161126 18:38:04< celticminstrel> I hadn't specifically planned it, until now. :P
20161126 18:38:08< EliDupree> heh
20161126 18:38:57< celticminstrel> I haven't been able to work on the wml_tag_porting branch at all recently. I wonder if I should just push what I have so far into master.
20161126 18:39:50< celticminstrel> Maybe excluding [animate_unit] since I haven't tested it yet.
20161126 18:39:57< celticminstrel> (Not even sure it's complete.)
20161126 18:44:53< vultraz> Sometimes I wonder if BfW is less "developing a game" and more "a million different programming exercises"
20161126 18:46:22< JyrkiVesterinen> At least for me it feels like "trying to keep stuff working".
20161126 18:48:26-!- Kwandulin [~Miranda@p200300760F6EBFED093A106372B9BA0A.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20161126 18:48:51< vultraz> let's be honest, maybe.. 5% of our effort is put towards the actual campaign stories :P
20161126 18:49:43< vultraz> 5% towards campaign WML.
20161126 18:49:53< vultraz> and 90% towards playing with internals
20161126 18:50:57< celticminstrel> So what's the other 5%?
20161126 18:52:00< vultraz> do you even math :P
20161126 18:52:47< vultraz> I said 5% campaign stories, 5% campaign WML, and 90% playing with internals.
20161126 18:52:50< celticminstrel> Yeah, just missed one of your percentages when I said that.
20161126 18:54:21< vultraz> Out of that 90%, 50% is spent saying "whhyyyyyy is x done this way"
20161126 18:54:31 * celticminstrel doubts your numbers though.
20161126 18:54:58< celticminstrel> Is that 50% of the total or 50% of the 90% (ie, 45% of the total)?
20161126 18:56:01< vultraz> the latter
20161126 18:56:36< celticminstrel> I just realized that "%" could be considered a shorthand for "times ten to the minus 2".
20161126 18:57:13< vultraz> ...oh?
20161126 18:57:38< celticminstrel> If you take it that way, the eg 50% == 0.5.
20161126 18:57:42< JyrkiVesterinen> "times 0.01" is literally what the percentage sign means. I have thought about that a couple of times.
20161126 18:58:10< celticminstrel> So 50%*90%=45% because 0.5*0.9=0.45.
20161126 18:59:06< vultraz> i have never thought of this 
20161126 18:59:30< vultraz> i always just looked at % as ... 'out of 100'  :/
20161126 18:59:52< celticminstrel> Well, that would come to the same thing if you think about it.
20161126 19:00:05< celticminstrel> 50% --> 50 out of 100 --> 50/100 --> 0.5
20161126 19:00:12< celticminstrel> Since "out of" implies division.
20161126 19:01:10< vultraz> hm yes
20161126 19:04:16-!- travis-ci [~travis-ci@ec2-54-166-157-46.compute-1.amazonaws.com] has joined #wesnoth-dev
20161126 19:04:17< travis-ci> wesnoth/wesnoth#12170 (dontshowmpwaitstarted - 3266baa : gfgtdf): The build has errored.
20161126 19:04:17< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/179073871
20161126 19:04:17-!- travis-ci [~travis-ci@ec2-54-166-157-46.compute-1.amazonaws.com] has left #wesnoth-dev []
20161126 19:22:24-!- ancestral [~ancestral@8.42.164.20] has joined #wesnoth-dev
20161126 19:24:50< irker622> wesnoth: gfgtdf wesnoth:dontshowmpwaitstarted fd09c5eaa38d / src/gui/dialogs/multiplayer/mp_join_game.cpp: Update mp_join_game.cpp https://github.com/wesnoth/wesnoth/commit/fd09c5eaa38ded6304cf2d6741924ba48166cfab
20161126 19:38:35< gfgtdf> JyrkiVesterinen: ^ i think this fixes my branch
20161126 19:46:09-!- ancestral [~ancestral@8.42.164.20] has quit [Quit: i go nstuf kthxbai]
20161126 19:46:34-!- ancestral [~ancestral@8.42.164.20] has joined #wesnoth-dev
20161126 19:47:19-!- ancestral [~ancestral@8.42.164.20] has quit [Client Quit]
20161126 19:58:46-!- JyrkiVesterinen [~JyrkiVest@87-100-193-182.bb.dnainternet.fi] has quit [Quit: Going to bed]
20161126 20:08:11< gfgtdf> the load map dialog n the editor takes quite some time to pen, is this known  issue ?
20161126 20:08:31< vultraz> gfgtdf: only for celticminstrel, and i think he fixed it.
20161126 20:09:00< gfgtdf> celticminstrel: i'm usng 1.13.6 release was, does 1.13.6 include your fix ?
20161126 20:09:42< celticminstrel> My load map issue is in both 1.13.6 and master, and it's not what you described.
20161126 20:09:48< celticminstrel> It's a crash upon opening the dialog.
20161126 20:09:59< vultraz> oh
20161126 20:10:59< celticminstrel> That includes the official 1.13.6 release, so even though ancestral/mattsc don't have the issue, ancestral's build demonstrates the issue on my computer.
20161126 20:23:35< irker622> wesnoth: gfgtdf wesnoth:dontshowmpwaitstarted 41a33279c341 / src/game_initialization/playcampaign.cpp: Update playcampaign.cpp https://github.com/wesnoth/wesnoth/commit/41a33279c341f3d8951cf85b0189b8af6dd784fe
20161126 20:25:54< irker622> wesnoth: gfgtdf wesnoth:master c78452d9627a / src/ (3 files in 2 dirs): skip mp wait if the game has already started https://github.com/wesnoth/wesnoth/commit/c78452d9627a8d26542d3acc9c37510384882f13
20161126 20:44:44-!- travis-ci [~travis-ci@ec2-54-166-157-46.compute-1.amazonaws.com] has joined #wesnoth-dev
20161126 20:44:45< travis-ci> wesnoth/wesnoth#12172 (dontshowmpwaitstarted - fd09c5e : gfgtdf): The build has errored.
20161126 20:44:46< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/179087315
20161126 20:44:46-!- travis-ci [~travis-ci@ec2-54-166-157-46.compute-1.amazonaws.com] has left #wesnoth-dev []
20161126 20:46:45-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Quit: wedge009]
20161126 20:47:46-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161126 20:51:45< irker622> wesnoth: Charles Dang wesnoth:master db161337f240 / src/sdl/color.hpp: Implement a few operators for color_t https://github.com/wesnoth/wesnoth/commit/db161337f24007f352f72fb15e248982c2c19d66
20161126 20:52:15< celticminstrel> You forgot !=
20161126 20:52:35< vultraz> D:
20161126 20:52:47< celticminstrel> If you implement == you should always implement != too.
20161126 20:52:58< vultraz> for the record, I dunno if that's the right way to "add" colors.
20161126 20:53:01< celticminstrel> Just return !this.operator==(c);
20161126 20:53:07< celticminstrel> That's vector addition.
20161126 20:53:22< celticminstrel> It's not how colour blending works, but it's fine as an approximation.
20161126 20:53:51< celticminstrel> (Or if you prefer infix notation: !(*this == c) )
20161126 20:54:22< celticminstrel> You could implement < if you want, but probably not needed (unless we want to use them as map keys).
20161126 20:54:25< vultraz> most code I've seen simply uses !operator==();
20161126 20:54:41< celticminstrel> That's assuming a global operator, not a class operator.
20161126 20:55:03< vultraz> ah
20161126 20:55:16< celticminstrel> ie !operator==(lhs, rhs)
20161126 20:55:54< irker622> wesnoth: Charles Dang wesnoth:master 83e288b61190 / src/sdl/color.hpp: color_t: implement operator!= https://github.com/wesnoth/wesnoth/commit/83e288b61190430e331c4cdcfc6c12024b89867f
20161126 20:56:16< celticminstrel> So you chose infix, huh.
20161126 20:56:28 * celticminstrel shrug
20161126 20:56:33< vultraz> it looks nicer
20161126 20:56:43< celticminstrel> Yeah, I kinda agree TBH.
20161126 20:56:56< celticminstrel> Though I also prefer keeping my comparison operators global.
20161126 20:57:06< celticminstrel> And arithmetic operators too.
20161126 20:57:30< celticminstrel> Oh, right, if you have + you should probably have += ... and normally, + is implemented in terms of +=.
20161126 20:57:45< vultraz> D:
20161126 20:57:50< vultraz> I thought that was implicit
20161126 20:58:05< celticminstrel> Seriously?
20161126 20:58:18< vultraz> yes :/
20161126 20:58:30< vultraz> should i just make + += instead?
20161126 20:58:54< pydsigner> < celticminstrel> Oh, right, if you have + you should probably have += ... and normally, + is implemented in terms of +=.
20161126 20:59:00< pydsigner> Isn't it the other way around?
20161126 20:59:08< celticminstrel> For + you can literally just "return c += this" as long as c is "color_t" instead of "const color_t&".
20161126 20:59:16< celticminstrel> pydsigner: Well, it could be done either way,
20161126 20:59:38< pydsigner> celticminstrel: But then you're modifying c, right?
20161126 20:59:52< celticminstrel> pydsigner: Right, but you've taken c as a copy.
20161126 20:59:58< celticminstrel> So that's fine.
20161126 21:00:03< pydsigner> Oh ok sure then
20161126 21:00:07-!- Greg-Boggs [~greg_bogg@c-76-115-139-154.hsd1.or.comcast.net] has quit [Remote host closed the connection]
20161126 21:00:14< celticminstrel> Sorry, *this not this.
20161126 21:00:40-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:ad9e:9fc1:fc47:250a] has joined #wesnoth-dev
20161126 21:00:41< celticminstrel> += wouldn't be the same as vultraz's + currently, since it modifies the current object instead of returning a new one.
20161126 21:00:59< celticminstrel> += implemented in terms of + would be something like "*this = *this + c", I think.
20161126 21:01:45-!- travis-ci [~travis-ci@ec2-54-242-240-19.compute-1.amazonaws.com] has joined #wesnoth-dev
20161126 21:01:46< travis-ci> wesnoth/wesnoth#12174 (dontshowmpwaitstarted - 41a3327 : gfgtdf): The build has errored.
20161126 21:01:47< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/179095259
20161126 21:01:47-!- travis-ci [~travis-ci@ec2-54-242-240-19.compute-1.amazonaws.com] has left #wesnoth-dev []
20161126 21:05:03-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:ad9e:9fc1:fc47:250a] has quit [Ping timeout: 245 seconds]
20161126 21:09:03< gfgtdf> vultraz: i think you want std::min<uint32_t> insteadof std::min<uint8_t> since the former casts both operands to uint8_t before the min operation is aplpied.
20161126 21:12:29< gfgtdf> vultraz: the later i meant
20161126 21:14:02< celticminstrel> Oh!
20161126 21:14:18< celticminstrel> vultraz: Your operator<< is totally broken.
20161126 21:14:25< celticminstrel> Because uint8_t is a char.
20161126 21:14:36< celticminstrel> So it's outputting the colour values as characters.
20161126 21:14:44< celticminstrel> You need to cast to int or something.
20161126 21:14:51< vultraz> I see
20161126 21:15:15< celticminstrel> (To be more precise, uint8_t is unsigned char. However, all three char types are treated as characters by the stream classes.)
20161126 21:15:30< celticminstrel> Alternatively you could store the components as uint16_t instead.
20161126 21:16:13< celticminstrel> gfgtdf: Isn't that what you want?
20161126 21:16:21< vultraz> wouldn't that make harder to make a uint32_t out of them?
20161126 21:16:33< celticminstrel> gfgtdf: Casting both to uint8_t before the min is applied, I mean.
20161126 21:17:32< celticminstrel> vultraz: Well, it would make it unsafe to use + instead of |.
20161126 21:17:41< celticminstrel> ...come to think of it, your to_rgba_uint32 is also broken.
20161126 21:17:52< celticminstrel> And would still be broken if they were uint16_t.
20161126 21:18:23< gfgtdf> celticminstrel: well if you cast to utin_8 beore than the min will have no effect since teh second parameter will always be <= 255.
20161126 21:18:29< celticminstrel> It's broken because r << 24 is always 0 no matter what r is, because 24 is greater than 8, the width of the type.
20161126 21:19:12< celticminstrel> gfgtdf: True, perhaps just a static_cast<uint8_t> would be better.
20161126 21:19:43< celticminstrel> vultraz: Also, I dislike the format you chose for the colour.
20161126 21:19:56< celticminstrel> Nothing about four space-separated numbers suggets a colour.
20161126 21:20:12< celticminstrel> The operator<< will mostly be used for debugging, I would guess?
20161126 21:20:20< celticminstrel> Like in log messages and such.
20161126 21:20:34< vultraz> yes
20161126 21:20:43< celticminstrel> You wouldn't be using lexical_cast?
20161126 21:20:43< vultraz> celticminstrel: as for format, I duplicated SDL_Color
20161126 21:20:50< celticminstrel> I see.
20161126 21:21:17< celticminstrel> Well, I prefer vector format (with parentheses and commas), but I guess it's not that important.
20161126 21:21:21< vultraz> (tough SDL_Color us Uint8 not uint8_t, but same difference)
20161126 21:21:39< gfgtdf> Uint8 is the same as uint8_t
20161126 21:21:45< celticminstrel> (As for how to fix to_rgba_uint32, you need to cast each component to uint32 before shifting.
20161126 21:22:03< celticminstrel> )
20161126 21:22:14< vultraz> you can edit the file too, you know
20161126 21:22:19< celticminstrel> (Well, alpha doesn't need a cast.)
20161126 21:22:25< celticminstrel> Good point. <_<
20161126 21:24:36< irker622> wesnoth: Celtic Minstrel wesnoth:master dbad85a55b66 / src/sdl/color.hpp: color_t: Fix some logic errors https://github.com/wesnoth/wesnoth/commit/dbad85a55b6624355cc2f2ed515a554a9602ce9d
20161126 21:25:12< vultraz> isn't int() the cast format we're not supposed to use?
20161126 21:25:23< celticminstrel> Yes. <_<
20161126 21:25:33 * celticminstrel in the middle of a second commit now.
20161126 21:28:55-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 265 seconds]
20161126 21:37:15< irker622> wesnoth: Celtic Minstrel wesnoth:master fc39435f3951 / src/sdl/color.hpp: color_t: Implement operator+= and handle overflow https://github.com/wesnoth/wesnoth/commit/fc39435f3951d963f7b244cd19b33dc454dcf826
20161126 21:39:00< celticminstrel> I just realized that vultraz's implementation would've worked if he simply used max instead of min.
20161126 21:39:24< vultraz> eh?
20161126 21:39:36< celticminstrel> r and c.r are uint8_t.
20161126 21:40:13< celticminstrel> So if the addition is >255, it wraps around to be less than 255 (as if you calculated (r+c.r)%256).
20161126 21:41:26< celticminstrel> Thus, with min(255,result), you choose the wrapped component, but with max(255,result), you choose 255.
20161126 21:41:40< celticminstrel> Which, presumably, was the intent of your implementation.
20161126 21:42:02< vultraz> yes
20161126 21:42:03< vultraz> that was
20161126 21:42:16< celticminstrel> All addition in C/C++ is implicitly modulo the size of the type.
20161126 21:43:02< celticminstrel> You can usually forget about it when working with int (which are 32-bit, so it's modulo 2^32), but with 8-bit integers you need to be aware of this.
20161126 21:43:15< celticminstrel> ^usually 32-bit
20161126 21:43:44< celticminstrel> (Also, if using signed integers, the wrapping is officially undefined behaviour.)
20161126 21:43:55< vultraz> I see
20161126 21:44:08< celticminstrel> (It's well-defined for unsigned integers though.)
20161126 21:56:49-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20161126 21:57:31< gfgtdf> celticminstrel: operarands of size > int are casts to int before each addition. even if both operatans are of this type
20161126 21:57:42< gfgtdf> celticminstrel: size < size (int) i meant
20161126 21:57:55< celticminstrel> Is that so?
20161126 21:58:01< celticminstrel> Well, you still need to be aware of it though.
20161126 21:58:07< gfgtdf> celticminstrel: yes
20161126 21:58:20< celticminstrel> Because even if it doesn't happen at the time of the addition, it almost certainly will happen at some point.
20161126 21:58:47< celticminstrel> For example, when assigning the result back to a variable of the same size.
20161126 23:04:02-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Quit: wedge009]
20161126 23:04:22-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161126 23:13:55-!- Bonobo [~Bonobo@2001:44b8:254:3200:a8a6:3514:c4c5:86ad] has joined #wesnoth-dev
20161126 23:14:58< vultraz> so apparently i didn't need to define the copy constructor
20161126 23:15:02< vultraz> why did i do so..
20161126 23:16:01< gfgtdf> vultraz: i asked myself that question too
20161126 23:16:43< vultraz> heh, actually, removing the copy constructor fixes a compiler error in the last commit
20161126 23:17:31< irker622> wesnoth: Charles Dang wesnoth:master efe6ad83425f / src/sdl/color.hpp: color_t: removed explicit copy constructor https://github.com/wesnoth/wesnoth/commit/efe6ad83425fdc3c6ea9765034d9653566cd68c4
20161126 23:18:25< celticminstrel> What was the compile error?
20161126 23:18:47< vultraz> something about there being no match for color_t(color_t& c)
20161126 23:18:58< celticminstrel> What line?
20161126 23:19:14< vultraz> return c += *this;
20161126 23:19:51< celticminstrel> Huh, I would've expected const color_t& to be able to bind to that.
20161126 23:21:17-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:ad9e:9fc1:fc47:250a] has joined #wesnoth-dev
20161126 23:23:15< vultraz> now we just wait for Aginor's feedback
20161126 23:23:39< celticminstrel> Maybe you should ping him if you want his feedback.
20161126 23:23:43< celticminstrel> Aginor: You around?
20161126 23:24:04< vultraz> I thought saying his name pinged him
20161126 23:24:22< vultraz> or is that only some irc clients
20161126 23:24:28< celticminstrel> Generally that's the case, yes, but it depends on the client.
20161126 23:24:52< celticminstrel> He has said before that he's only pinged if the message starts with his name.
20161126 23:25:11< celticminstrel> Possible even his name plus a colon, not sure/
20161126 23:25:49< vultraz> oh
20161126 23:25:50< vultraz> blah
20161126 23:25:51-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:ad9e:9fc1:fc47:250a] has quit [Ping timeout: 258 seconds]
20161126 23:26:16< celticminstrel> Basically, what pings people is dependent on the person. :P
20161126 23:26:43< celticminstrel> I've set my client to ping me on either celmin, celeticminstrel, or CM. It also adds my current nick to that.
20161126 23:27:34< celticminstrel> However it's case-sensitive for CM and doesn't ping on celmin followed by a period.
20161126 23:27:44< celticminstrel> Oh right, it also pings on celt, celtic, and minstrel
20161126 23:28:28< celticminstrel> Also celmin. does ping but celmin.com or similar would not.
20161126 23:28:47< celticminstrel> (Note: that domain does not exist to my knowledge, it was just an example.)
20161126 23:29:00< celticminstrel> (Domains are in fact the reason for the rule.)
20161126 23:31:58< Ravana_> I have tried to exclude Mal-Ravanal, though with limited success
20161126 23:32:44< celticminstrel> ???
20161126 23:32:48< vultraz> xD
20161126 23:32:55< celticminstrel> Oh.
20161126 23:33:07< celticminstrel> My client only matches full words.
20161126 23:46:02-!- mjs-de [~mjs-de@x4e312c17.dyn.telefonica.de] has joined #wesnoth-dev
20161126 23:46:46-!- mjs-de [~mjs-de@x4e312c17.dyn.telefonica.de] has quit [Remote host closed the connection]
--- Log closed Sun Nov 27 00:00:54 2016