--- Log opened Sun Sep 25 00:00:44 2016
20160925 00:05:12-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Ping timeout: 240 seconds]
20160925 00:05:27< matthiaskrgr> what other channel? 
20160925 00:05:31 * matthiaskrgr is in 42 chanels
20160925 00:06:55-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20160925 00:07:18-!- Bonobo [~Bonobo@2001:44b8:254:3200:a0cb:2ee:8dd8:57a4] has joined #wesnoth-dev
20160925 00:10:09< mattsc> matthiaskrgr: okay, I can reproduce that now.  No error message, but no recruiting either.
20160925 00:10:16< mattsc> I’ll look into that.  Thanks.
20160925 00:11:26< matthiaskrgr> \o/ yay
20160925 00:19:36< pydsigner> matthiaskrgr: #devuan
20160925 00:23:30< matthiaskrgr> Im not active there :o
20160925 00:47:05< pydsigner> You /nick'ed
20160925 00:47:45-!- louis94 [~~louis94@91.178.241.111] has quit [Ping timeout: 276 seconds]
20160925 00:48:30-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 250 seconds]
20160925 01:14:44< matthiaskrgr> oh
20160925 01:22:12-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160925 01:26:18< mattsc> matthiaskrgr: so what’s happening with the ExpAI is kind of funny here.
20160925 01:27:16< mattsc> The AI engine internally does not know about shroud, so it is finding hexes to recruit all over the place in the long stretched-out castle.
20160925 01:28:04< mattsc> But then when it tries to actually recruit on a shrouded hex, the engine barks at it with error 3006: E_BAD_RECRUIT_LOCATION 
20160925 01:28:57< matthiaskrgr> heh
20160925 01:29:10< mattsc> So the fix for that is relatively simple.
20160925 01:29:27< mattsc> That does not explain why the other side gets drakes though.
20160925 01:29:31< matthiaskrgr> and how did the humans come to recruit drakes? 
20160925 01:29:36< matthiaskrgr> ah :) 
20160925 01:31:47< mattsc> which, btw, I have not seen so far
20160925 01:32:03< matthiaskrgr> hmm
20160925 01:35:03< mattsc> matthiaskrgr: I assume that with “humans” you mean loyalists, right?
20160925 01:35:07< matthiaskrgr> yes
20160925 01:35:30< mattsc> Every time I let them play this match-up, they’ve only recruited Loyalists.
20160925 01:36:12< matthiaskrgr> mh ok 
20160925 01:38:27< mattsc> Now, how do I find out in Lua whether a hex is shrouded …
20160925 01:38:40< mattsc> SLF with [filter_vision], I guess
20160925 01:39:14< mattsc> Can a human player recruit on a fogged hex?
20160925 01:39:46< mattsc> Yes.
20160925 01:40:31< mattsc> But not on a shrouded hex, obviously.
20160925 01:40:52< celticminstrel> Can that distinguish between shroud and fog though?
20160925 01:41:00< celticminstrel> [filter_vision] I mean.
20160925 01:41:25 * celticminstrel seems to recall that FormulaAI actually has a function for getting a recruitable castle tile.
20160925 01:42:11< mattsc> celticminstrel: not sure at the moment, I am still trying some other things
20160925 01:43:05< mattsc> Also, what happens if you try to recruit on a fogged hex that has an enemy unit on it?
20160925 01:43:09< mattsc> Let’s see ...
20160925 01:44:28< mattsc> Huh, the unit is recruited next to the leader instead …
20160925 01:44:34< matthiaskrgr> lol
20160925 01:46:27< celticminstrel> Probably just treats it as if you tried to recruit without specifying a hex.
20160925 01:46:45-!- RatArmy [~RatArmy@240f:b3:88e3:1:9200:4eff:fe1a:914d] has quit [Quit: Leaving]
20160925 01:47:05< mattsc> That would be my guess
20160925 01:47:08< celticminstrel> I'd say that it's pretty rare to have a fogged hex that you can recruit to though - castles aren't usually that big. As far as I know?
20160925 01:47:59< mattsc> Right, but Arcenclave Citadel is one where you can.
20160925 01:48:15< mattsc> And I am sure there is various UMC out there that does that too.
20160925 01:48:30< mattsc> Arcanclave; or whatever
20160925 01:49:13< mattsc> “respect_fog: yes or no, default yes. "yes" filters for locations that are clear of both fog and shroud, "no" filters for locations that are clear of shroud.”
20160925 01:49:41< mattsc> So it should be possible to distinguish between fog and shroud
20160925 01:50:04< mattsc> Although for the ExpAI, it might make more sense to only use entirely clear hexes.
20160925 01:53:53-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160925 01:55:27-!- allefant is now known as elias
20160925 01:59:38-!- VultCave [~chatzilla@124.109.10.167] has joined #wesnoth-dev
20160925 01:59:56-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Read error: Connection reset by peer]
20160925 02:00:06< mattsc> So looking through the code, actions/create.cpp does a check for vacant tile (when recruiting, recalling, …) that does a shroud check.
20160925 02:00:39< mattsc> If that fails, that reports back to the recruiting action and that raises error E_BAD_RECRUIT_LOCATION as shown above
20160925 02:00:57< mattsc> So yes, that’s definitely the problem here.
20160925 02:04:08-!- VultCave [~chatzilla@124.109.10.167] has quit [Ping timeout: 265 seconds]
20160925 02:14:52-!- TC02 [~quassel@venus.arosser.com] has joined #wesnoth-dev
20160925 02:15:19-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160925 02:17:13-!- irker014 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160925 02:17:13< irker014> wesnoth: Charles Dang wesnoth:master 6797e82414fe / src/image_modifications.cpp: Fixup 55ba8c95bcc48 (~O was broken) https://github.com/wesnoth/wesnoth/commit/6797e82414fedc4ad5e0afefe942a06610fe0462
20160925 02:17:45< irker014> wesnoth: mattsc wesnoth:master 3d0c29b7fc3f / data/ai/lua/generic_recruit_engine.lua: Experimental AI: do not let AI try to recruit on fogged/shrouded hexes https://github.com/wesnoth/wesnoth/commit/3d0c29b7fc3f7f2d544ecc247cb58c9f8cfcbe7c
20160925 02:17:58< mattsc> matthiaskrgr: ^
20160925 02:18:43< mattsc> I’d be interested in knowing whether your loyalists-can-recruit-drakes problem is gone too.  I don’t see how this would be related, but as I said, I could not reproduce it in the first place.
20160925 02:22:24< matthiaskrgr> /home/matthias/vcs/github/wesnoth2/wesnoth/src/image_modifications.cpp: In member function ‘virtual surface image::o_modification::operator()(const surface&) const’:
20160925 02:22:29< matthiaskrgr> /home/matthias/vcs/github/wesnoth2/wesnoth/src/image_modifications.cpp:458:14: warning: comparison is always false due to limited range of data type [-Wtype-limits]
20160925 02:22:36< matthiaskrgr> if (amount < 0) amount = 0;
20160925 02:25:09< vultraz> :| :| :| :| :|
20160925 02:53:31-!- travis-ci [~travis-ci@ec2-54-144-100-165.compute-1.amazonaws.com] has joined #wesnoth-dev
20160925 02:53:32< travis-ci> wesnoth/wesnoth#11183 (master - 6797e82 : Charles Dang): The build failed.
20160925 02:53:32< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/162514551
20160925 02:53:32-!- travis-ci [~travis-ci@ec2-54-144-100-165.compute-1.amazonaws.com] has left #wesnoth-dev []
20160925 02:58:01< EliDupree> Long story short, the idea of "train some neural networks somehow and then port them to lua" definitely looks promising. I don't think I'm going to do it right away (the last 2 days of screwing around with prototypes haven't really gotten me excited, and I have other things I could be doing), but I'll probably try that out eventually.
20160925 03:08:27< matthiaskrgr> loyalists still recruiting drakes :/
20160925 03:10:29< matthiaskrgr> and the exp. ai is still not recruiting
20160925 03:10:31< matthiaskrgr> :/
20160925 03:10:57< matthiaskrgr> 20160925 05:09:51 error engine/team_construction: found invalid side=2 in definition of side number 1
20160925 03:11:00< matthiaskrgr> 20160925 05:09:51 error engine/team_construction: found invalid side=1 in definition of side number 2
20160925 03:12:05< mattsc> That does not sound like an AI problem.
20160925 03:14:37< matthiaskrgr> well, it might be related to why the loyalists recruit drakes
20160925 03:15:06< matthiaskrgr> anyway, on my side it looks like the commit didn't change anything
20160925 03:18:18< matthiaskrgr> need to get some sleep. gn
20160925 03:22:54-!- travis-ci [~travis-ci@ec2-54-167-138-16.compute-1.amazonaws.com] has joined #wesnoth-dev
20160925 03:22:55< travis-ci> wesnoth/wesnoth#11184 (master - 3d0c29b : mattsc): The build failed.
20160925 03:22:55< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/162514601
20160925 03:22:55-!- travis-ci [~travis-ci@ec2-54-167-138-16.compute-1.amazonaws.com] has left #wesnoth-dev []
20160925 03:34:18< vultraz> is there any good test for the brighten/darken modifications?
20160925 03:34:46< vultraz> already-existing test, that is
20160925 03:35:47< vultraz> ..huh, actually, those functions do not do what one would think they do
20160925 03:38:01< celticminstrel> ?
20160925 03:38:42< vultraz> "Puts a time-of-day overlay on the image"
20160925 03:38:51< celticminstrel> ...eh?
20160925 03:39:22< vultraz> idk
20160925 03:39:28< vultraz> what does that even mean
20160925 03:39:41< celticminstrel> That's what I'm wondering.
20160925 03:40:25< celticminstrel> ...they're literally just a blit. o.o
20160925 03:40:51< celticminstrel> Do they have a dev-tag on the wiki?
20160925 03:41:01< vultraz> no
20160925 03:41:08< vultraz> I'm guessing they have to do with uh
20160925 03:41:25< vultraz> the overlay on the tod images with, say the mage of light
20160925 03:45:23< celticminstrel> So what's the difference between this and blit?
20160925 03:45:59< vultraz> ah indeed
20160925 03:46:04< vultraz> nothing, it seems
20160925 03:46:14< celticminstrel> Surprisingly there does appear to be a difference, possibly.
20160925 03:46:23< celticminstrel> Specifically, blit passes a destrect while these do not.
20160925 03:46:30< celticminstrel> Not entirely sure what that means in practice.
20160925 03:46:55< celticminstrel> It might mean nothing.
20160925 03:47:06< vultraz> it means 'blit over the entire surface'
20160925 03:47:41< celticminstrel> So basically ~BRIGHTEN() squashes or stretches it to cover the whole image?
20160925 03:48:02< vultraz> I'd say so..
20160925 03:48:11< vultraz> it doesn't work if you say, use it on a unit, though
20160925 03:48:16< vultraz> might be my local change, though
20160925 03:48:20< vultraz> let me confirm.
20160925 03:48:22< celticminstrel> What?
20160925 03:49:07< vultraz> I'm testing whether various modifications can be made to use sdl_blit instead of our custom blit_surface
20160925 03:49:11< vultraz> so far, the results are promising
20160925 03:49:51< vultraz> now, need to test ~BG somehow..
20160925 03:49:53< vultraz> "Sets the color of all the (semi-)transparent pixels of the image."
20160925 03:51:20< vultraz> what is a good case for testing this :|
20160925 03:53:19< vultraz> ok, behavior is consistent
20160925 03:54:14< celticminstrel> vultraz: Sounds like that's equivalent to "making a solid-colour canvas and pasting the image over it".
20160925 04:02:33< vultraz> I could have sworn I had reverted the changes that somehow got in my stash...
20160925 04:02:35< vultraz> blah
20160925 04:02:36< vultraz> :|
20160925 04:02:38< vultraz> *long build*
20160925 04:09:25< vultraz> celticminstrel: is it possible to clear a stash?
20160925 04:09:55< celticminstrel> git stash drop stash@{n}
20160925 04:10:00< celticminstrel> But make sure you really want to first.
20160925 04:10:11< celticminstrel> Probably with git stash show -p stash@{n}
20160925 04:10:37< celticminstrel> Because once dropped I'm pretty sure it's gone for good.
20160925 04:13:40-!- Bonobo [~Bonobo@2001:44b8:254:3200:a0cb:2ee:8dd8:57a4] has quit [Ping timeout: 255 seconds]
20160925 04:13:56-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 250 seconds]
20160925 04:14:00-!- Bonobo [~Bonobo@2001:44b8:254:3200:a0cb:2ee:8dd8:57a4] has joined #wesnoth-dev
20160925 04:15:40< irker014> wesnoth: Charles Dang wesnoth:master 31b08a25f2a4 / data/core/images/misc/blank-hex.png: Properly save blank-hex.png as full alpha instead of hex-masked https://github.com/wesnoth/wesnoth/commit/31b08a25f2a489b3c26d8408ed2b4e36d0b7d333
20160925 04:15:43< irker014> wesnoth: Charles Dang wesnoth:master 6bfe9d01098c / src/image_modifications.cpp: Use sdl_blit instead of custom blitting function (blit_surface) for IPF function https://github.com/wesnoth/wesnoth/commit/6bfe9d01098cd70dbe9239d721b036f85dea2638
20160925 04:15:46< irker014> wesnoth: Charles Dang wesnoth:master 00b271546057 / src/image_modifications.cpp: Fixup 6797e82414fe https://github.com/wesnoth/wesnoth/commit/00b271546057b169b3d0d6f3c8602e9243d52602
20160925 04:15:53-!- iceiceice [~chris@unaffiliated/iceiceice] has joined #wesnoth-dev
20160925 04:17:35< vultraz> so, about 31b08a25f2a4 
20160925 04:18:12< vultraz> though it looks like there's no change, for some reason the old file resulted in a hex-shaped mask when blitted onto using sdl_blit
20160925 04:18:38< vultraz> since it's used widely as a base canvas, I simply resaved it as a full-alpha image.
20160925 04:19:54< vultraz> and it allows it to match the behavior observed with blit_surface
20160925 04:21:12< iceiceice> btw, i was spectating a game from this international tournament recently
20160925 04:21:20< iceiceice> got a pretty interesting bug report against 1.12
20160925 04:21:52< iceiceice> the russian and polish players said that all the "filter" boxes in the game do not handle umlaut characters properly
20160925 04:22:08< iceiceice> when you type "alt-a" or whatever for umalut a charaacter
20160925 04:22:12< vultraz> very possibly
20160925 04:22:17< vultraz> I think that was fixed in 1.13
20160925 04:22:34< iceiceice> ok cool :)
20160925 04:29:30< irker014> wesnoth: Charles Dang wesnoth:master 67348181f5d2 / src/editor/ (3 files in 2 dirs): Use sdl_blit instead of custom blitting function (blit_surface) in editor https://github.com/wesnoth/wesnoth/commit/67348181f5d27cf7ca093c3bf688c28a904c1ffa
20160925 04:37:44< vultraz> celticminstrel: bug: when typing in the text box, wml menu item hotkeys can still trigger for the hovered unit
20160925 04:37:47< vultraz> command box*
20160925 04:38:02< celticminstrel> Fun! :|
20160925 04:46:01< celticminstrel> vultraz: https://gna.org/bugs/?12098
20160925 04:46:33< vultraz> what about it?
20160925 04:46:40< vultraz> you introduced 2-portrait messages already
20160925 04:46:52< celticminstrel> See latest comment.
20160925 04:47:54< vultraz> well i cant access the screenshot
20160925 04:48:41< celticminstrel> You could try the code he posted? Basically the options are cut off even though there's lots of empty space between them and the right portrait.
20160925 04:49:32< vultraz> ill look into it
20160925 04:51:05< irker014> wesnoth: Charles Dang wesnoth:master 07e993ce3e32 / src/ (8 files in 4 dirs): Convert more cases of blit_surface to sdl_blit https://github.com/wesnoth/wesnoth/commit/07e993ce3e3228924e338e842a63da4761b8df73
20160925 04:52:53-!- travis-ci [~travis-ci@ec2-54-167-138-16.compute-1.amazonaws.com] has joined #wesnoth-dev
20160925 04:52:54< travis-ci> wesnoth/wesnoth#11185 (master - 00b2715 : Charles Dang): The build was fixed.
20160925 04:52:54< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/162521803
20160925 04:52:54-!- travis-ci [~travis-ci@ec2-54-167-138-16.compute-1.amazonaws.com] has left #wesnoth-dev []
20160925 04:56:30< vultraz> hmm
20160925 04:56:32< vultraz> not sure..
20160925 05:16:16-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20160925 05:22:46< vultraz> Aginor: ok, I think I've removed all uses of custom blitting except for 3 uses in the GUI2 canvas code
20160925 05:22:51< vultraz> Aginor: 1 for text and 2 for images
20160925 05:23:34< Aginor> vultraz: good job
20160925 05:23:45-!- travis-ci [~travis-ci@ec2-54-234-225-120.compute-1.amazonaws.com] has joined #wesnoth-dev
20160925 05:23:46< travis-ci> wesnoth/wesnoth#11186 (master - 6734818 : Charles Dang): The build was fixed.
20160925 05:23:46< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/162522522
20160925 05:23:46-!- travis-ci [~travis-ci@ec2-54-234-225-120.compute-1.amazonaws.com] has left #wesnoth-dev []
20160925 05:25:48< vultraz> Aginor: I'm not sure how to handle the canvas cases, however, since they do not work correctly with a drop-in of sdl_blit
20160925 05:30:41< iceiceice> oh btw
20160925 05:31:02< iceiceice> does anyone have the experience that, wesnoth puts ... in a filename of a save if the automatically generated name is long?
20160925 05:31:14< vultraz> wha?
20160925 05:32:19< iceiceice> if you play tekelili's add-on
20160925 05:32:21< iceiceice> "world conquest 2"
20160925 05:32:27< iceiceice> if oftne puts "..." in your autosave filenames
20160925 05:32:30< iceiceice> which is kind of annoying
20160925 05:32:33< iceiceice> (in 1.12)
20160925 05:32:36< iceiceice> don't know if it does that in 1.14
20160925 05:33:34< vultraz> oh, I think I fixed something like that
20160925 05:34:41< vultraz> dunno if it fixes autosaves, though
20160925 05:34:49< vultraz> but it think it should have
20160925 05:35:36< iceiceice> awesome
20160925 05:36:54< vultraz> Aginor: so again, the problem is that images/text has incorrect transparency when blitted to canvas, both can be fixed by setting the image/text blend mode to NONE, but that obviously causes problems and not what we want
20160925 05:38:02-!- Kwandulin [~Miranda@p200300760F2C7144C864162A4E3E7CD4.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160925 05:38:27< vultraz> I'm just not sure where to look for the "right"solution
20160925 05:47:38< vultraz> would appreciate anyone's suggestions
20160925 05:50:37-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20160925 05:51:05< vultraz> hm
20160925 05:51:13< vultraz> "Source surface blend mode set to SDL_BLENDMODE_BLEND:
20160925 05:51:15< vultraz> alpha-blend (using the source alpha-channel and per-surface alpha) SDL_SRCCOLORKEY ignored."
20160925 05:51:24< vultraz> pre-surface as in premultiplied ?
20160925 06:10:13-!- noy [~Noy@wesnoth/developer/noy] has quit [Read error: Connection reset by peer]
20160925 06:11:01-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20160925 06:19:18-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160925 06:21:28-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Client Quit]
20160925 06:44:42-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160925 06:45:17-!- mjs-de [~mjs-de@x4db64afe.dyn.telefonica.de] has joined #wesnoth-dev
20160925 06:48:17-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 250 seconds]
20160925 06:48:18-!- wedge010 is now known as wedge009
20160925 06:49:00-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20160925 06:55:13-!- Kwandulin [~Miranda@p200300760F2C7144C864162A4E3E7CD4.dip0.t-ipconnect.de] has quit [Ping timeout: 255 seconds]
20160925 06:56:43-!- mjs-de [~mjs-de@x4db64afe.dyn.telefonica.de] has quit [Remote host closed the connection]
20160925 07:10:49-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: GO, GET TO THE CHOPPAH!!!]
20160925 07:10:53-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160925 07:12:24-!- Kwandulin [~Miranda@p200300760F2C715AC864162A4E3E7CD4.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160925 07:31:58< vultraz> ok, this is... interesting :/
20160925 07:32:41< vultraz> in decode_pixel..
20160925 07:33:40< vultraz> if i swap the formula order, the text looks great.. but it's all black :P
20160925 07:36:31< vultraz> need to text to look great AND look like the actual color :P
20160925 07:51:19-!- irker014 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160925 08:24:11-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20160925 08:28:52-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 265 seconds]
20160925 08:41:15-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20160925 08:42:19-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20160925 08:43:43-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Client Quit]
20160925 08:46:51< zookeeper> vultraz, blank-hex.png _had_ "full alpha". alpha channel was 0 on every pixel. what you did is change the RGB values, and if the masking code requires that for masking to work right, then there's still a problem with the code.
20160925 08:54:00-!- Kwandulin [~Miranda@p200300760F2C715AC864162A4E3E7CD4.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160925 09:04:23-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20160925 09:59:07-!- Kwandulin [~Miranda@p200300760F2C715A65AFD6538A68A2D5.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160925 10:00:54-!- Appleman1234 [~Appleman1@KD119104043152.au-net.ne.jp] has quit [Ping timeout: 276 seconds]
20160925 10:08:41< zookeeper> there's something eerily broken about ambushers that have a standing animation. that is, they turn invisible. and that's not just the bug in master, it happens in 1.12 too.
20160925 10:09:16< zookeeper> namely, i have a wose with a standing animation which has some filtering and stuff, and as a result the unit is just... completely invisible.
20160925 10:09:22< zookeeper> no sprite, ellipse, bars, nothing
20160925 10:10:08< zookeeper> although actually that doesn't seem to even require ambush
20160925 10:10:22< zookeeper> ahh now i get it. false alarm, i think. nevermind!
20160925 10:11:48 * zookeeper didn't realize that having the filtered standing anim was enough to dissipate the default standing anim, leaving the unit animless until the filtered animation ran
20160925 10:12:38-!- louis94 [~~louis94@91.178.242.7] has joined #wesnoth-dev
20160925 10:18:15-!- Appleman1234 [~Appleman1@KD119104057188.au-net.ne.jp] has joined #wesnoth-dev
20160925 10:26:44 * zookeeper wonders whether it's possible to suppress the automatic fadeout at the end of a death animation
20160925 10:32:34< zookeeper> seems like a pretty unavoidable, looking at the code
20160925 10:37:35-!- louis94 [~~louis94@91.178.242.7] has quit [Ping timeout: 260 seconds]
20160925 10:38:16-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20160925 10:56:07-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20160925 11:16:43-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160925 11:21:26-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20160925 11:25:13-!- Bonobo [~Bonobo@2001:44b8:254:3200:a0cb:2ee:8dd8:57a4] has quit [Ping timeout: 255 seconds]
20160925 11:25:32-!- Bonobo [~Bonobo@2001:44b8:254:3200:a0cb:2ee:8dd8:57a4] has joined #wesnoth-dev
20160925 11:34:07-!- esr1 is now known as esr
20160925 11:42:24-!- enchi [~aeonchild@defocus/yummy/enchilado] has quit [Ping timeout: 250 seconds]
20160925 11:43:38-!- enchi [enchilado@defocus/yummy/enchilado] has joined #wesnoth-dev
20160925 11:56:32-!- JyrkiVesterinen [~JyrkiVest@87-100-160-35.bb.dnainternet.fi] has joined #wesnoth-dev
20160925 12:14:43< EliDupree> More AI thoughts from last night: https://gist.githubusercontent.com/elidupree/562fc7eac151ac7a8f988e7923ac9949/raw/90abbcf97f87a344a36802df06aa7de9f8cb0ca5/gistfile1.txt
20160925 12:24:13-!- RatArmy [~RatArmy@240f:b3:88e3:1:9200:4eff:fe1a:914d] has joined #wesnoth-dev
20160925 12:25:16-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Read error: Permission denied]
20160925 12:25:38-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20160925 12:36:40-!- RatArmy [~RatArmy@240f:b3:88e3:1:9200:4eff:fe1a:914d] has quit [Quit: Leaving]
20160925 12:47:25-!- trewe [~trewe@2001:8a0:d10e:d601:1efe:16f9:ac31:1d34] has joined #wesnoth-dev
20160925 13:20:00-!- Kwandulin [~Miranda@p200300760F2C715A65AFD6538A68A2D5.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160925 13:29:09-!- midzer_ is now known as midzer
20160925 13:35:33-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20160925 13:44:14-!- vultraz [~chatzilla@124.109.10.167] has joined #wesnoth-dev
20160925 13:44:14-!- vultraz [~chatzilla@124.109.10.167] has quit [Changing host]
20160925 13:44:14-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160925 13:47:29< vultraz> interesting, interesting...
20160925 13:47:33< vultraz> I've made progress
20160925 13:49:26< vultraz> I can get the text to display nicely, again, but without the proper color :|
20160925 13:51:20-!- Kwandulin [~Miranda@p200300760F2C715AC556DC832654D4DE.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160925 13:52:33< vultraz> so the color 'decode' formula is p[i] = p[i] * div / 256
20160925 13:52:49< vultraz> div is decode_table.values[alpha - 1]...
20160925 13:53:31< vultraz> if I average the value of [alpha -1] AND alpha the text looks pretty good.. but off-color..
20160925 13:55:02< vultraz> likewise for averaging p[i] and p[i + 1], though that makes less sense since p is supposed to be the color data of a pixel..
20160925 13:56:43-!- gfgtdf [~chatzilla@x4e36ac7c.dyn.telefonica.de] has joined #wesnoth-dev
20160925 13:57:05< vultraz> not exactly sure why it divides the number by 256 after multiplying by alpha..
20160925 13:57:21< vultraz> (and why 256 and not 255)
20160925 13:57:41< vultraz> but obviously that's the area where it gets 'true color'
20160925 13:58:32< vultraz> so I think I need to adjust for the extra multip accumulated by averaging the alpha..
20160925 14:01:23< vultraz> ugh, no..
20160925 14:03:51< vultraz> oh, wait :/
20160925 14:03:57< vultraz> blagh
20160925 14:04:06< vultraz> ok, not as much progress as I had hoped
20160925 14:09:17-!- Bonobo [~Bonobo@2001:44b8:254:3200:a0cb:2ee:8dd8:57a4] has quit [Quit: Leaving]
20160925 14:13:46< zookeeper> <zookeeper> vultraz, blank-hex.png _had_ "full alpha". alpha channel was 0 on every pixel. what you did is change the RGB values, and if the masking code requires that for masking to work right, then there's still a problem with the code.
20160925 14:14:32< vultraz> uh....
20160925 14:14:46< vultraz> what do you mean, required for it to work right
20160925 14:15:30< zookeeper> well surely you edited the image for some reason?
20160925 14:15:33< vultraz> yes
20160925 14:15:34< zookeeper> like, to fix something?
20160925 14:15:56< zookeeper> well, there you go. if that edit is necessary to fix something, then there's something wrong with the masking code.
20160925 14:16:09< vultraz> when using SDL_BlitSurface instead of our custom blit implementation, you could see an outline of a hex when people ~BLIT-ted stuff on top
20160925 14:16:35< vultraz> what was the rbg value before?
20160925 14:16:38< vultraz> rgb
20160925 14:17:48< vultraz> (what I mean by 'outline of a hex' is that the first (I think) image blitted on top was cropped to the shape of a hex)
20160925 14:17:56< zookeeper> black outside the hex and white inside, or vice versa
20160925 14:18:05< vultraz> I see
20160925 14:18:10< zookeeper> alpha was 0 everywhere
20160925 14:18:32< zookeeper> was there some scaling of anything involved when you saw the outline?
20160925 14:18:35 * zookeeper is afk for a bit
20160925 14:18:41< vultraz> no
20160925 14:18:57< vultraz> so you're saying it was a fully transparent version of terrain/alpha.png?
20160925 14:19:33< vultraz> (or perhaps alphamask.png)
20160925 14:19:35< vultraz> ie, 255,255,255,0 and 0,0,0,0?
20160925 14:21:27-!- irker279 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160925 14:21:27< irker279> wesnoth: mattsc wesnoth:master f7fd9ee77ee6 / data/campaigns/The_Rise_Of_Wesnoth/ai/ (ca_aggressive_attack_no_suicide.lua ca_retreat.lua): TRoW S15: fix custom Lua CAs to conform to new syntax https://github.com/wesnoth/wesnoth/commit/f7fd9ee77ee6b5eb0d5a54e4f6dee1d693dc6f8d
20160925 14:22:38< vultraz> either way, I see no problem with making it all 1 'color'
20160925 14:24:43< gfgtdf> vultraz: i think that point is that if there was a problem with the c++ code that changes behaviour when handling this imange, then the proper fix is not to change this image, pecially since there migth be addons that relied on th prevous behaviour.
20160925 14:25:55< vultraz> sdl_blit is just a wrapper for SDL_BlitSurface. I'm more inclined to say we follow whatever SDL does than the behavior of our custom blit function
20160925 14:26:17< vultraz> the behavior matches with the edit to the image
20160925 14:26:20< vultraz> I see no problem
20160925 14:31:46< EliDupree> This discussion reminds me of a problem I noticed a while ago: ~SCALE() being dependent on the RGB values of fully transparent pixels (for instance, the duelist image had transparent white pixels, so it got a blurry white border when scaled up, but most units had black transparent pixels, so it wasn't a problem because they had a black border anyway)
20160925 14:32:56< vultraz> oh?
20160925 14:33:01-!- gfgtdf_ [~chatzilla@x4e36ac7c.dyn.telefonica.de] has joined #wesnoth-dev
20160925 14:34:32< irker279> wesnoth: Charles Dang wesnoth:master 2ef46193c9d8 / src/text.cpp: Text: cleanup and a small 'fix' to the rendering code https://github.com/wesnoth/wesnoth/commit/2ef46193c9d8a52bf352050419224e95cbe49bc4
20160925 14:34:33< vultraz> ^ not related to the text rendering issue
20160925 14:34:47< zookeeper> vultraz, yes it was... except the colors were inverted (i checked now)
20160925 14:35:06< vultraz> so, alphamask.png
20160925 14:35:37< zookeeper> EliDupree, yeah that's an annoying problem
20160925 14:35:52< zookeeper> so far i haven't succeeded in goading anyone to try to fix it :p
20160925 14:35:55< EliDupree> heh
20160925 14:36:30-!- gfgtdf [~chatzilla@x4e36ac7c.dyn.telefonica.de] has quit [Ping timeout: 264 seconds]
20160925 14:36:41-!- gfgtdf_ is now known as gfgtdf
20160925 14:37:03< vultraz> EliDupree: do you mean SCALE or SCALE_SHARP?
20160925 14:37:26< zookeeper> it's the same issue as with ~BL
20160925 14:37:30< EliDupree> There's a SCALE_SHARP?
20160925 14:37:33< vultraz> yes?
20160925 14:37:36< zookeeper> which is actually the one i've tried to get people to fix
20160925 14:38:27< vultraz> EliDupree: pixel art will be blurry by design when using SCALE unless you use SCALE_SHARP
20160925 14:38:34< zookeeper> i expect that it affects all functions which use any kind of interpolation
20160925 14:38:41< vultraz> unless you mean the portrait?
20160925 14:39:08< EliDupree> vultraz: I just mean that I never heard of that particular image mod. And now I'm having trouble finding the image mod page on the wiki too
20160925 14:39:16< vultraz> https://wiki.wesnoth.org/ImagePathFunctionWML#SCALE:_Image-scaling_function
20160925 14:39:44< zookeeper> the problem, put simply: when blurring or scaling, the RGB values of fully transparent pixels affect the output. they shouldn't.
20160925 14:41:05< EliDupree> I see, it's in 1.13 only
20160925 14:41:48< zookeeper> i believe you can workaround the bug by first blitting the image onto a black transparent bg, or something like that
20160925 14:41:53< zookeeper> i'm not sure though
20160925 14:41:56< vultraz> there's a white line around the dueling portrait, yes.
20160925 14:42:00< vultraz> duelist
20160925 14:42:11< vultraz> but that's not the fault of scaling
20160925 14:42:13< vultraz> it's in the image
20160925 14:42:20< EliDupree> zookeeper: Only if you can tolerate removing the transparency in the final image
20160925 14:42:38< zookeeper> vultraz, that's exactly what we're talking about
20160925 14:42:53< vultraz> zookeeper: yes, so the fix is to remove it from the image.
20160925 14:42:57< zookeeper> no!
20160925 14:43:19< zookeeper> well, okay, yeah one could fix those little white pixels
20160925 14:43:33< zookeeper> but that's not the issue we're talking about... or at least not me :p
20160925 14:43:38< vultraz> open the duelist portrait in an image editor. create a fully black, opaque layer underneath. I see some white pixels around it.
20160925 14:44:07< vultraz> now if you mean the duelist *sprite*
20160925 14:44:18< EliDupree> vultraz: yes, we do
20160925 14:44:24< vultraz> sprite?
20160925 14:44:32< EliDupree> yes
20160925 14:45:22< zookeeper> huh
20160925 14:45:36< zookeeper> the sprite has some 255,255,255,1 pixels
20160925 14:45:44< EliDupree> haha
20160925 14:45:46< vultraz> :|
20160925 14:45:50< zookeeper> how strange
20160925 14:45:58< vultraz> that's not fully transparent now, is it :)
20160925 14:46:15< EliDupree> So maybe the algorithm wasn't at fault? Although the algorithm should still give the nearly-transparent pixels less weight
20160925 14:46:23< zookeeper> lemme fix those right away...
20160925 14:46:52< zookeeper> the algo is still wrong
20160925 14:48:15-!- yaiyan is now known as Yaiyan
20160925 14:48:55< zookeeper> gah, the animations are full of that crap too...
20160925 14:49:02< zookeeper> i hate when people are super sloppy with their images
20160925 14:49:36< vultraz> you do realize the duelist sprite is very old
20160925 14:49:47< vultraz> likely before we had quality control.
20160925 14:49:53< vultraz> from before*
20160925 14:50:21< zookeeper> ...
20160925 14:51:39< vultraz> what>
20160925 14:51:41< vultraz> ?
20160925 14:51:42< vultraz> is it not old?
20160925 14:52:21< EliDupree> I think the keeper is just saying it's still annoying even if it's old
20160925 14:52:41< EliDupree> *zookeeper, dammit speech-2-text
20160925 14:52:58< zookeeper> i'm just saying that you probably have some weird delusions about when we started having "quality control"
20160925 14:53:11< zookeeper> and what that even entails
20160925 14:53:34< vultraz> Just that early wesnoth had a way lower bar for entry than it does today.
20160925 14:54:13< zookeeper> certainly. but that's not the same as "lol no quality control"
20160925 14:54:21< zookeeper> anyway i'll fix those duelist sprites, will take a moment
20160925 14:54:44< EliDupree> Yeah, the duelist has been around for about as long as I have. We had some really crap sprites back then
20160925 14:55:39< vultraz> quality is directly correlated to a high bar of entry
20160925 14:55:53< zookeeper> EliDupree, well then we remember that even the crossbow is a new invention. it used to have a _pistol_ :p
20160925 14:56:00< EliDupree> lol
20160925 14:56:09< vultraz> a pistol, you say?
20160925 14:56:12< zookeeper> and that horrible super loud gunshot sound
20160925 14:56:17< vultraz> why was this removed?
20160925 14:56:17< EliDupree> yup!
20160925 14:57:11< zookeeper> and everyone had ugg.wav for their hit sound
20160925 14:57:30< EliDupree> That's why the sprite still doesn't hold the crossbow correctly, but instead, holds it the way you would hold a pistol
20160925 14:57:55< vultraz> I had wondered about that..
20160925 14:58:02< vultraz> we should get a new sprite anyway
20160925 14:58:05< EliDupree> haha
20160925 14:58:38< zookeeper> oh wait, we had groan.wav back then too
20160925 14:59:00< vultraz> then again, that's an ok grip for a min-crossbow
20160925 14:59:04< zookeeper> the good times...
20160925 14:59:50< EliDupree> Of course. A mini-crossbow that does more damage than a trained swordsman hitting you with a sword.
20160925 15:00:20< EliDupree> Although, I suppose I shouldn't appeal to realism.
20160925 15:00:37< zookeeper> yeah, i think someone once invented a handy acronym to use when someone tries to do that
20160925 15:00:41< zookeeper> now what was it...
20160925 15:00:41< EliDupree> :)
20160925 15:01:36< vultraz> wesnoth takes a lot of artistic license :P
20160925 15:01:44< vultraz> "attack dude while standing on a mountain"
20160925 15:02:01< vultraz> "standing unit attacks flying unit"
20160925 15:03:07< vultraz> "heavily armed behemoth is annoyed by bat"
20160925 15:03:14< vultraz> and armored*
20160925 15:03:52< vultraz> "village? you mean house?
20160925 15:04:20< vultraz> "perfect vision underground once you've walked somewhere once"
20160925 15:05:49< irker279> wesnoth: ln-zookeeper wesnoth:master 9d1346ed572a / data/core/images/units/human-loyalists/ (12 files): Removed unintended non-transparent white pixels https://github.com/wesnoth/wesnoth/commit/9d1346ed572aa237c236415a4987255351744cfd
20160925 15:06:43< EliDupree> "Very good archer is able to fire 5 arrows in only 4 hours!"
20160925 15:07:08< zookeeper> oh man, some of these old optimization runs... "Ran optipng, saved 471 kB (1%) on 4667 files." gee, good trade
20160925 15:07:37< matthiaskrgr> lol 
20160925 15:09:16< matthiaskrgr> zookeeper: for the record, with the new script (wip) I got     3583534 b (3 Mb) -> 2691575 b (2 Mb) => [-891959 b (-871 kb)]      with a 10 % threshold 
20160925 15:09:47< matthiaskrgr> should be able to finish that today
20160925 15:11:06 * zookeeper does not compute
20160925 15:11:44< matthiaskrgr> I am rewriting wesnoth-optipng in python
20160925 15:12:20< zookeeper> yeah your numbers just don't tell me anything
20160925 15:12:29< matthiaskrgr> ah
20160925 15:13:16< matthiaskrgr> I modify around 3.5 megabyte of files, and these 3.5 megabyte become 2.6 megabyte of files
20160925 15:13:37< zookeeper> ah, okay. how many files is that?
20160925 15:13:43< matthiaskrgr> 619 
20160925 15:13:46< matthiaskrgr> er
20160925 15:13:48< matthiaskrgr> 603 
20160925 15:14:33< zookeeper> also shame on you Jetrel_; the while pixels i just fixed date back to your duelist sprites from 2005 :>
20160925 15:14:52< zookeeper> matthiaskrgr, okay, cool
20160925 15:15:08-!- travis-ci [~travis-ci@ec2-54-144-100-165.compute-1.amazonaws.com] has joined #wesnoth-dev
20160925 15:15:09< travis-ci> wesnoth/wesnoth#11188 (master - f7fd9ee : mattsc): The build has errored.
20160925 15:15:09< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/162576414
20160925 15:15:09-!- travis-ci [~travis-ci@ec2-54-144-100-165.compute-1.amazonaws.com] has left #wesnoth-dev []
20160925 15:15:35< zookeeper> s/while/white
20160925 15:16:27< matthiaskrgr> now take a guess, how much would coverting all pngs to flif save? :P 
20160925 15:16:49< matthiaskrgr> or did I already tell this 
20160925 15:16:53< zookeeper> you didn't
20160925 15:16:56< matthiaskrgr> ok ^^ 
20160925 15:17:14< zookeeper> let's guess... uh... all images? let's say 8mb
20160925 15:17:16< matthiaskrgr> (without threshould and default flif compression) 
20160925 15:17:19< matthiaskrgr> hah! 
20160925 15:17:21< matthiaskrgr> 61 MB 
20160925 15:17:25< zookeeper> O__________o
20160925 15:17:28< matthiaskrgr> ^_^
20160925 15:17:42< matthiaskrgr> 172 MB -> 111 MB 
20160925 15:17:50< zookeeper> well that is certainly impressive
20160925 15:18:00< matthiaskrgr> yes :) 
20160925 15:18:21< vultraz> better solution: use spritesheets
20160925 15:18:44< matthiaskrgr> and there's still room for improvement (maybe another 5-10 % )
20160925 15:23:59< zookeeper> matthiaskrgr, not that i'm suggesting you to do it, but in an ideal world the compression tool would come with a nifty little slider which you could move around and decide the accept/discard threshold and see the resulting number of changed files and the total filesize savings in real time :P
20160925 15:25:02< matthiaskrgr> I just finished implementing the threshold  :> 
20160925 15:25:08< matthiaskrgr> well
20160925 15:25:27< matthiaskrgr> the slider thing is gonna be difficult without gui 
20160925 15:25:48< matthiaskrgr> currently I process files all individually 
20160925 15:26:08< matthiaskrgr> (I don't do a big compare at the end as the current script does) 
20160925 15:27:04< matthiaskrgr> current status:  http://pastebin.com/SHXjKWpH  
20160925 15:28:04< zookeeper> i'm sure we can live without a gui
20160925 15:28:37< zookeeper> one just might want to do an iteration or two to narrow down a suitable threshold
20160925 15:31:03< matthiaskrgr> the nice is tricky though
20160925 15:31:32< matthiaskrgr> oh, maybe not
20160925 15:33:21-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Read error: Connection reset by peer]
20160925 15:33:45-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160925 15:46:07< matthiaskrgr> hmhm, statistics are a bit tricky because I'd need a thread lock 
20160925 15:46:24< matthiaskrgr> for accessing variables by different threads 
20160925 15:48:23< matthiaskrgr> unless I do a bulk of IO before and after processing 
20160925 16:00:30-!- gfgtdf [~chatzilla@x4e36ac7c.dyn.telefonica.de] has quit [Ping timeout: 264 seconds]
20160925 16:02:38-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160925 16:03:14-!- gfgtdf [~chatzilla@x4e36ac7c.dyn.telefonica.de] has joined #wesnoth-dev
20160925 16:09:21< vultraz> zookeeper, celticminstrel, shadowm, Aginor, Ivanovic, Jetrel_bot, iceiceice, loonycyborg, Soliton, Rhonda, JyrkiVesterinen, bumbadadabum: just a final reminder to vote by Monday if you have not yet done so.
20160925 16:09:28< vultraz> and intend to, that is
20160925 16:09:37< bumbadadabum> I'm fine with any candidate
20160925 16:09:42< bumbadadabum> so idk if I should vote
20160925 16:11:17-!- mkdroid [~null@unaffiliated/matthiaskrgr] has joined #wesnoth-dev
20160925 16:11:29< vultraz> up to you
20160925 16:11:39< vultraz> but voting for everyone is essentially voting for no-one
20160925 16:12:20< DeFender> what are you guys voting for?
20160925 16:12:39< vultraz> wesnoth.inc board positions, see link in topic.
20160925 16:13:23-!- Kwandulin [~Miranda@p200300760F2C715AC556DC832654D4DE.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160925 16:13:46< DeFender> Ah. Fun times.
20160925 16:14:35< DeFender> is there a reason it's limited to three? Seems like with 5 candidates, you could just make all 5 the board and be done with it, no?
20160925 16:15:30< vultraz> too many cooks 
20160925 16:16:19< DeFender> Fair enough.
20160925 16:37:20-!- mjs-de [~mjs-de@x4db64afe.dyn.telefonica.de] has joined #wesnoth-dev
20160925 16:43:59-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20160925 16:50:26< irker279> wesnoth: Jyrki Vesterinen wesnoth:master 76d407e733b9 / / (8 files in 4 dirs): Expose preferences to Lua https://github.com/wesnoth/wesnoth/commit/76d407e733b9bf1e0cc62a8c79f0ab69151242c1
20160925 16:50:28< irker279> wesnoth: Jyrki Vesterinen wesnoth:master c2d3607d4959 / / (3 files in 2 dirs): Restrict preference access to plugins https://github.com/wesnoth/wesnoth/commit/c2d3607d4959022685c319a9ca503357c3cd873c
20160925 16:50:30< irker279> wesnoth: Jyrki Vesterinen wesnoth:master 02b2ac5a17d3 / src/ (4 files in 2 dirs): Address feedback https://github.com/wesnoth/wesnoth/commit/02b2ac5a17d365f64aff46669a09df8e32b0d4cd
20160925 16:50:32< irker279> wesnoth: Jyrki Vesterinen wesnoth:master 4e49f2647d87 / / (10 files in 3 dirs): Merge pull request #786 from wesnoth/expose-preferences-to-lua https://github.com/wesnoth/wesnoth/commit/4e49f2647d870c3fe42b35c2559264504168e04b
20160925 16:57:51< irker279> wesnoth: Espreon wesnoth:master 7e9941441a3b / po/wesnoth/en@shaw.po: Fixed time formatting characters for en@shaw https://github.com/wesnoth/wesnoth/commit/7e9941441a3b7d311a39e6b568cbede9cc4b277c
20160925 17:00:12-!- Espreon [~espreon@wesnoth/developer/espreon] has joined #wesnoth-dev
20160925 17:00:57< Espreon> wedge009: I'm not sure what OS you use, but in my experience, on Linux at least, only editors that use GTK really work well with files that have Shavian characters.
20160925 17:01:12< Espreon> As for why this happened, I believe they used a transliterator to do most of the work.
20160925 17:01:23< Espreon> Or how, rather.
20160925 17:01:58< vultraz> can the bug be marked as fixed?
20160925 17:02:13< Espreon> I don't know.
20160925 17:02:29< vultraz> well, thanks for fixing anyway
20160925 17:02:51< Espreon> I suspect what should be done is to at least have bad input discarded and to have an error message thrown somewhere.
20160925 17:02:57< Espreon> No prob.
20160925 17:03:13< irker279> wesnoth: Charles Dang wesnoth:master 9ccc4300b993 / projectfiles/CodeBlocks/wesnoth.cbp: Update CB projfile https://github.com/wesnoth/wesnoth/commit/9ccc4300b993dcdaf5e166ce20a5256a4cc60bf8
20160925 17:06:00-!- mkdroid [~null@unaffiliated/matthiaskrgr] has quit [Ping timeout: 276 seconds]
20160925 17:06:37-!- mkdroid [~null@unaffiliated/matthiaskrgr] has joined #wesnoth-dev
20160925 17:07:13-!- mordante [~mordante@2001:984:5786:1:7a24:afff:fe8c:dea8] has joined #wesnoth-dev
20160925 17:07:13-!- mordante [~mordante@2001:984:5786:1:7a24:afff:fe8c:dea8] has quit [Changing host]
20160925 17:07:13-!- mordante [~mordante@wesnoth/developer/mordante] has joined #wesnoth-dev
20160925 17:07:25< mordante> servus
20160925 17:16:03< irker279> wesnoth: Jyrki Vesterinen wesnoth:master 419a30b45edb / src/gui/ (dialogs/multiplayer/mp_staging.cpp widgets/chatbox.cpp): Cherry-pick useful parts of pull request #801 https://github.com/wesnoth/wesnoth/commit/419a30b45edb01d8f88333950fbd8539e89175d4
20160925 17:18:21< irker279> wesnoth: Jyrki Vesterinen wesnoth:enable-gui2-lobby-in-gui2-lobby-test e1895e8eaa2b / host-gui2.lua host.lua join-gui2.lua join.lua: Enable the GUI2 lobby in the GUI2 lobby test https://github.com/wesnoth/wesnoth/commit/e1895e8eaa2b87e453be3dfd7707e8c7ca0a2ec7
20160925 17:18:23< irker279> wesnoth: Jyrki Vesterinen wesnoth:enable-gui2-lobby-in-gui2-lobby-test 1c97c8890cde / utils/travis/mp_test_executor-gui2.sh: Mark mp_test_executor-gui2.sh as executable https://github.com/wesnoth/wesnoth/commit/1c97c8890cde402520e4b76d3f2aeeb6cb7a9ec4
20160925 17:18:48< irker279> wesnoth: Jyrki Vesterinen wesnoth:master e1895e8eaa2b / host-gui2.lua host.lua join-gui2.lua join.lua: Enable the GUI2 lobby in the GUI2 lobby test https://github.com/wesnoth/wesnoth/commit/e1895e8eaa2b87e453be3dfd7707e8c7ca0a2ec7
20160925 17:18:50< irker279> wesnoth: Jyrki Vesterinen wesnoth:master 1c97c8890cde / utils/travis/mp_test_executor-gui2.sh: Mark mp_test_executor-gui2.sh as executable https://github.com/wesnoth/wesnoth/commit/1c97c8890cde402520e4b76d3f2aeeb6cb7a9ec4
20160925 17:18:52< irker279> wesnoth: Jyrki Vesterinen wesnoth:master a29c669866ea / host-gui2.lua host.lua join-gui2.lua join.lua utils/travis/mp_test_executor-gui2.sh: Merge pull request #787 from wesnoth/enable-gui2-lobby-in-gui2-lobby-test https://github.com/wesnoth/wesnoth/commit/a29c669866eacf2d610ab652293fcbd816d7ecdd
20160925 17:19:45< JyrkiVesterinen> ^ I dropped the commit that enabled the GUI2 MP test in Travis. We don't want to turn the test on as long as it's failing.
20160925 17:22:01-!- hk238 [~kvirc@unaffiliated/hk238] has joined #wesnoth-dev
20160925 17:25:35< vultraz> I can't really figure out how to get staging fully network-compatible
20160925 17:25:56< vultraz> so I was hoping gfgtdf could
20160925 17:29:37-!- gfgtdf [~chatzilla@x4e36ac7c.dyn.telefonica.de] has quit [Read error: Connection reset by peer]
20160925 17:30:46-!- travis-ci [~travis-ci@ec2-54-163-206-61.compute-1.amazonaws.com] has joined #wesnoth-dev
20160925 17:30:47< travis-ci> wesnoth/wesnoth#11191 (master - 4e49f26 : Jyrki Vesterinen): The build has errored.
20160925 17:30:47< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/162596621
20160925 17:30:47-!- travis-ci [~travis-ci@ec2-54-163-206-61.compute-1.amazonaws.com] has left #wesnoth-dev []
20160925 17:32:31< EliDupree> Hmm. My Lua code is doing a series of costly operations that change a lot of terrain. My code is invoking wesnoth.fire ("redraw"), which works SOMETIMES, but eventually it freezes up and stops redrawing in a way that the user can see. Does anyone know why this is happening or what a good workaround might be?
20160925 17:33:20< EliDupree> (The operations do eventually finish and the final state becomes visible to the user, but it's no fun if they have to sit around staring at a static screen in the meantime)
20160925 17:33:48< vultraz> odd...
20160925 17:33:58< EliDupree> (The redraw occurs between each change and the next)
20160925 17:34:05< vultraz> a bug was discovered recently having to do with redraw...
20160925 17:34:32< EliDupree> What was it? I've had various trouble getting clean redraws through my entire work and EoHS
20160925 17:35:06< vultraz> thot s11, a change to the unit's variation didn't show on-screen despite [redraw]
20160925 17:39:17< vultraz> mordante: had any chance to look at the credits thing?
20160925 17:41:43< mordante> vultraz, not yet, has been a busy week
20160925 17:43:24< vultraz> ok, whenever you have a chance
20160925 17:45:24< EliDupree>       wesnoth.fire ("redraw")
20160925 17:45:24< EliDupree>       wesnoth.fire ("delay",{time = 10})
20160925 17:45:24< EliDupree>       wesnoth.fire ("redraw")
20160925 17:45:36< EliDupree> This succeeded as a workaround for my issue.
20160925 17:46:38< vultraz> interesting
20160925 17:46:40-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.]
20160925 17:48:34-!- hk238 [~kvirc@unaffiliated/hk238] has quit [Quit: http://www.kvirc.net/ 4.9.2 Aria]
20160925 17:52:54-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160925 17:57:48-!- travis-ci [~travis-ci@ec2-54-161-173-250.compute-1.amazonaws.com] has joined #wesnoth-dev
20160925 17:57:49< travis-ci> wesnoth/wesnoth#11192 (master - 7e99414 : Espreon): The build was broken.
20160925 17:57:49< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/162597676
20160925 17:57:49-!- travis-ci [~travis-ci@ec2-54-161-173-250.compute-1.amazonaws.com] has left #wesnoth-dev []
20160925 17:58:16< tad_> en@shaw.po:5601: end-of-line within string en@shaw.po:5605: end-of-line within string /usr/bin/msgfmt: found 2 fatal errors make[2]: *** [po/CMakeFiles/mo-update.dir/build.make:3505: translations/en@shaw/LC_MESSAGES/wesnoth.mo] Error 1 make[1]: *** [CMakeFiles/Makefile2:196: po/CMakeFiles/mo-update.dir/all] Error 2
20160925 17:59:53< tad_> So, is this known? Should I wait or should I look at the error?
20160925 18:00:42< tad_> I see Travis-ci is getting the same error
20160925 18:01:18< vultraz> Espreon: ^
20160925 18:03:49< tad_> vultraz: I was hoping to build against master before asking but that's not currently possible, so: we still having problems with units not displaying?
20160925 18:05:36< vultraz> I have not been able to to reproduce that myself
20160925 18:06:13-!- mkdroid [~null@unaffiliated/matthiaskrgr] has quit [Quit: I'll be back!]
20160925 18:07:28-!- Kwandulin [~Miranda@p200300760F2C715A1941A6C269CC1ECC.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160925 18:08:05< tad_> vultraz: I checked .. hmm .. maybe 12 hours ago and all I needed was units with standing anims and just sit and watch .. every few frames they'd fade out and back in.
20160925 18:08:24< vultraz> oh?
20160925 18:08:27< vultraz> standing animations?
20160925 18:08:29< vultraz> i was not told this
20160925 18:08:31< vultraz> will look
20160925 18:10:00< tad_> I was looking at DiD S02, expose the map, create units by villages (not all, just a few) and capture them. sit and wait. Wife called, GTG, sorry.
20160925 18:10:05-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20160925 18:11:25-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20160925 18:13:41< Espreon> Oh, how lovely...
20160925 18:13:53< Espreon> Let's see...
20160925 18:20:12< vultraz> what the actual fucking fuck is this bug O_O
20160925 18:22:03< vultraz> how does this even...
20160925 18:22:08< vultraz> what the actual *fuck* :|
20160925 18:22:22< Espreon> Hmmm...?
20160925 18:22:24 * zookeeper slaps vultraz
20160925 18:22:25< zookeeper> behave
20160925 18:22:33< Espreon> Thank you, zookeeper.
20160925 18:22:51-!- travis-ci [~travis-ci@ec2-54-145-73-89.compute-1.amazonaws.com] has joined #wesnoth-dev
20160925 18:22:52< travis-ci> wesnoth/wesnoth#11193 (master - 9ccc430 : Charles Dang): The build was broken.
20160925 18:22:52< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/162598750
20160925 18:22:52-!- travis-ci [~travis-ci@ec2-54-145-73-89.compute-1.amazonaws.com] has left #wesnoth-dev []
20160925 18:26:39-!- louis94 [~~louis94@91.178.242.7] has joined #wesnoth-dev
20160925 18:28:39< irker279> wesnoth: Espreon wesnoth:master e607e791c7f8 / po/wesnoth/en@shaw.po: Removed extraneous quotation marks from wesnoth/en@shaw.po https://github.com/wesnoth/wesnoth/commit/e607e791c7f82d55dd481701e186a5fb6b1a12e7
20160925 18:28:53< Espreon> vultraz: ^
20160925 18:28:55< Espreon> Sorry.
20160925 18:34:06-!- mordante [~mordante@wesnoth/developer/mordante] has quit [Quit: Leaving]
20160925 18:37:27< Espreon> Oh shoot.
20160925 18:37:52-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 265 seconds]
20160925 18:40:21-!- travis-ci [~travis-ci@ec2-54-161-173-250.compute-1.amazonaws.com] has joined #wesnoth-dev
20160925 18:40:22< travis-ci> wesnoth/wesnoth#11195 (enable-gui2-lobby-in-gui2-lobby-test - 1c97c88 : Jyrki Vesterinen): The build has errored.
20160925 18:40:22< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/162600502
20160925 18:40:22-!- travis-ci [~travis-ci@ec2-54-161-173-250.compute-1.amazonaws.com] has left #wesnoth-dev []
20160925 18:44:47-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160925 18:46:56-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160925 18:47:28-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 265 seconds]
20160925 18:47:29-!- wedge010 is now known as wedge009
20160925 18:47:40< irker279> wesnoth: Espreon wesnoth:master fe2534edf4fa / po/wesnoth/en@shaw.po: Fixed remaining time formatting strings in wesnoth/en@shaw.po https://github.com/wesnoth/wesnoth/commit/fe2534edf4fa425c2a41e66a8306437b37a8015c
20160925 18:47:46< Espreon> I forgot we had so many now...
20160925 18:48:40-!- travis-ci [~travis-ci@ec2-54-161-173-250.compute-1.amazonaws.com] has joined #wesnoth-dev
20160925 18:48:41< travis-ci> wesnoth/wesnoth#11194 (master - 419a30b : Jyrki Vesterinen): The build was broken.
20160925 18:48:41< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/162600238
20160925 18:48:41-!- travis-ci [~travis-ci@ec2-54-161-173-250.compute-1.amazonaws.com] has left #wesnoth-dev []
20160925 18:50:22-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160925 18:56:27-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20160925 18:57:09-!- minzbonbon [~min@meta23.net] has quit [Ping timeout: 276 seconds]
20160925 18:57:16-!- minzbonbon [~min@meta23.net] has joined #wesnoth-dev
20160925 19:23:21-!- travis-ci [~travis-ci@ec2-54-145-73-89.compute-1.amazonaws.com] has joined #wesnoth-dev
20160925 19:23:22< travis-ci> wesnoth/wesnoth#11197 (master - a29c669 : Jyrki Vesterinen): The build was broken.
20160925 19:23:22< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/162600604
20160925 19:23:22-!- travis-ci [~travis-ci@ec2-54-145-73-89.compute-1.amazonaws.com] has left #wesnoth-dev []
20160925 19:25:30< vultraz> ...good god why do we have an entire file dedicated to map labels :|
20160925 19:27:13< DeFender> because map labels are important.
20160925 19:27:53< vultraz> no, that's not the point
20160925 19:28:06< DeFender> and because some of the organization in wesnoth's source sucks.
20160925 19:28:17< vultraz> there shouldn't need to be 600+ dedicated lines of code to do something so simple :|
20160925 19:28:21< DeFender> i know it's not. i was just being facetious.
20160925 19:28:45< DeFender> ah, that's... excessive
20160925 19:29:36< DeFender> your original line though reminded me of how there's an entire directory each dedicated to the scoprion's single sprite and the skeletal dragon's single sprite.
20160925 19:30:13< vultraz> well, those are supposed to get animation frames :P
20160925 19:30:20< vultraz> though spritesheets would be better
20160925 19:30:29< vultraz> but of course, *engine restrictions*
20160925 19:30:52< DeFender> fine, but even so things that have multiple animation sprites, such as the cuttlefish are all in the directory with everything else.
20160925 19:31:12< vultraz> yeah, those are the older sprites
20160925 19:31:32< DeFender> regarding engine restrictions, spritesheets ARE possible with copious use of ~CROP.
20160925 19:31:57< DeFender> though that's hardly better than separate files
20160925 19:32:04< vultraz> oh, yes
20160925 19:32:16< vultraz> but that's incredibly inefficient given the current engine :)
20160925 19:32:54< DeFender> as i said.
20160925 19:32:59-!- Kwandulin [~Miranda@p200300760F2C715A1941A6C269CC1ECC.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160925 19:33:27< vultraz> I think the cause of wesnoths' clutter can simply be summed up by the fact that it wasn't designed with a bi picture in mind
20160925 19:33:37< vultraz> instead, people just tacked on features as they wanted
20160925 19:33:44< vultraz> without considering a bigger design
20160925 19:34:27< DeFender> that tends to happen with most projects
20160925 19:34:40< vultraz> or view towards a shared API between sections :|
20160925 19:35:10< DeFender> at a certain point, it becomes more time efficient to just rebuild the architecture from scratch
20160925 19:35:18-!- louis94 [~~louis94@91.178.242.7] has quit [Ping timeout: 264 seconds]
20160925 19:35:24< DeFender> the logic can usually be reused
20160925 19:35:45< DeFender> and the graphics and wml certainly can
20160925 19:36:04< DeFender> (well, in this case. not true of projects that don't have graphics and wml)
20160925 19:36:09< vultraz> yeah, well that's a ton of work for 3 people :P
20160925 19:36:18< DeFender> but redoing an entire architecture is a hug-yeah
20160925 19:36:45 * DeFender wonders if such a thing could be done iteratively
20160925 19:37:37< DeFender> like, having the ultimate goal planned out, and then making interim changes that get closer to the ultimate goal of a unified and intelligent architecture.
20160925 19:37:49< vultraz> Maybe
20160925 19:37:58< vultraz> There are two options, really.
20160925 19:38:04< vultraz> What you propose is one
20160925 19:38:15< vultraz> The other is throw everything out the window :P
20160925 19:38:44< vultraz> Right now we're trying to do what you describe
20160925 19:38:53< vultraz> first step, unify the UI
20160925 19:41:02< vultraz> if nothing else, this is great experience in project management, long-term planning and execution, and How Not To Make a Game :P
20160925 19:45:34-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20160925 19:51:14-!- travis-ci [~travis-ci@ec2-54-163-206-61.compute-1.amazonaws.com] has joined #wesnoth-dev
20160925 19:51:15< travis-ci> wesnoth/wesnoth#11198 (master - e607e79 : Espreon): The build was fixed.
20160925 19:51:15< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/162610284
20160925 19:51:15-!- travis-ci [~travis-ci@ec2-54-163-206-61.compute-1.amazonaws.com] has left #wesnoth-dev []
20160925 20:07:38-!- JyrkiVesterinen [~JyrkiVest@87-100-160-35.bb.dnainternet.fi] has quit [Quit: .]
20160925 20:11:33-!- gfgtdf [~chatzilla@x4e36ac7c.dyn.telefonica.de] has joined #wesnoth-dev
20160925 20:12:16-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20160925 20:19:51-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 265 seconds]
20160925 20:20:14-!- louis94 [~~louis94@91.178.242.7] has joined #wesnoth-dev
20160925 20:32:17-!- louis94 [~~louis94@91.178.242.7] has quit [Ping timeout: 240 seconds]
20160925 20:46:24-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160925 20:54:38-!- iceiceice [~chris@unaffiliated/iceiceice] has quit [Quit: Ex-Chat]
20160925 20:59:24-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has quit [Quit: Connection closed for inactivity]
20160925 21:03:00-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: End Transmission.]
20160925 21:12:35< Rhonda> Did Jetrel rename?  I remember them by jetryl?
20160925 21:13:14< Rhonda> Seems to be the same person, and I'm quite certain that I want them on board from what I perceived from them in the past. :)
20160925 21:14:20< shadowm> Yes.
20160925 21:15:12< zookeeper> oh wait how many hours are there left to vote?
20160925 21:15:57< shadowm> Who knows. Dave didn't bother specifying a time zone, so I'd assume UTC-13?
20160925 21:16:25< zookeeper> well i guess i'll just do it right away
20160925 21:16:26< shadowm> Or UTC-12, whichever is the one that actually exists.
20160925 21:20:31< shadowm> Although perhaps it'd be safer to assume his own timezone, which is PDT I think.
20160925 21:20:57-!- tomreyn_ is now known as tomreyn
20160925 21:21:15< shadowm> I'm just a bit annoyed that some people still don't bother with timezones when dealing with an international audience.
20160925 21:22:30< shadowm> And this whole endeavor seems a bit flimsy.
20160925 21:22:58< tad_> "a bit"?
20160925 21:23:15< Rhonda> If no timezone is given I assume UTC. :)
20160925 21:23:25< Rhonda> Everything else is insane.
20160925 21:24:07< tad_> Bah. Just route your vote via Hawaii at 23:59 local and claim he didn't specify
20160925 21:24:08 * Rhonda . o O ( on the other hand, dave is from the US, uses non-metric systems, so what do I know  *runsandhides* )
20160925 21:24:59-!- TheJJ [~rofl@ipbcc36896.dynamic.kabel-deutschland.de] has joined #wesnoth-dev
20160925 21:25:25< DeFender> timezones are evil
20160925 21:25:39< DeFender> well, okay, timezones i can mostly deal with. It's DST that's evil.
20160925 21:25:58< Rhonda> Never look at the update history of the tzdata package …  >.>
20160925 21:26:30< shadowm> loonycyborg: I just noticed this in the campaignd log that I forgot to check regularly: 20160925 04:58:20 error server: <unknown address>       Connection timed out
20160925 21:27:13-!- TheJJ [~rofl@ipbcc36896.dynamic.kabel-deutschland.de] has quit [Read error: Connection reset by peer]
20160925 21:27:35-!- gfgtdf [~chatzilla@x4e36ac7c.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 49.0.1/20160922113459]]
20160925 21:27:44< shadowm> 20160924 10:55:04 error server: <unknown address>       Broken pipe
20160925 21:27:50< shadowm> 20160924 12:38:07 error server: <unknown address>       Connection reset by peer
20160925 21:27:56< shadowm> Etcetera.
20160925 21:28:34< loonycyborg> what's notable here? unknown address?
20160925 21:28:47< shadowm> ... Yes.
20160925 21:29:35< shadowm> Surely you can't lose track of who's at the other end when reporting a connection error, right?
20160925 21:29:49< tad_> Depends.
20160925 21:30:24< loonycyborg> it just queries the address using asio, but in some cases it can't tell an address
20160925 21:30:27-!- TheJJ [~rofl@ipbcc36896.dynamic.kabel-deutschland.de] has joined #wesnoth-dev
20160925 21:30:27< shadowm> At least, I don't think the server would or should report on its own actions on the listening socket.
20160925 21:30:31< loonycyborg> when socket is long destroyed
20160925 21:30:38< loonycyborg> or something
20160925 21:31:20< shadowm> Why would the socket be already destroyed?
20160925 21:31:22< tad_> Half opened can do it. So can a response on a never-used/long-closed socket. And, of course, software error can cause it, too.
20160925 21:31:57< tad_> shadowm: Close it on the server side. Wait for TIME_WAIT to expire then have the client reset the connection.
20160925 21:32:46< shadowm> Why would the server close a socket and then continue to care about it somehow?
20160925 21:32:57< shadowm> By the way, this is the server.
20160925 21:33:02< tad_> That's how TCP works.
20160925 21:33:20< tad_> It's called TIME_WAIT state.
20160925 21:33:48< Aginor> shadowm: sockets have 3 different states of closedness
20160925 21:34:20< Aginor> 1. Server closes it (meaning, server isn't intending to send more data)
20160925 21:34:33< Aginor> 2. Client closes it (client won't send more data)
20160925 21:34:40< Aginor> 3. Closed on both sides
20160925 21:35:11< Aginor> it's perfectly valid for one side of the conversation to close it for sending while still receiving data
20160925 21:35:28< tad_> The TCP RFC shows the state machines.
20160925 21:35:47< shadowm> But then you automatically lose track of what the client end was?
20160925 21:35:55< shadowm> s/client/opposite/
20160925 21:36:17< tad_> Anyway. To these messages. If they're infrequent and random just ignore them if you can't find any programming errors.
20160925 21:36:54< shadowm> I am reporting this to loonycyborg because he wrote this code and hasn't really been specific about what I or anyone should expect.
20160925 21:37:19< Aginor> shadowm: the socket is still valid until it is fully closed
20160925 21:37:21< shadowm> I can't know whether there are any logic errors around here and I honestly don't want to know.
20160925 21:37:27< loonycyborg> I remember getting unknown addresses in my local tests too, I forgot the details, but I remember concluding that sockets interface doesn't always know a socket's address
20160925 21:37:33< Aginor> and the socket is your unique identifier for that conversation
20160925 21:37:51< loonycyborg> and that getting more reliable addresses would require adding some state to socket_ptr
20160925 21:38:39< loonycyborg> even then it's not guaranteed to always have an address
20160925 21:38:49< loonycyborg> since it might not know it YET
20160925 21:38:58 * tad_ nods.
20160925 21:39:28< tad_> If the messages become persistent, I'd drop in a packet logger and see what's up. Otherwise, coderead and ignore 'em.
20160925 21:40:05< shadowm> Okay, just noting that this is the first piece of software I've seen reporting errors on connections to unknown addresses.
20160925 21:40:31-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20160925 21:41:25-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 260 seconds]
20160925 21:49:08-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20160925 21:49:11-!- irker279 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160925 21:55:11< tad_> shadowm: actually it's not that unusual. having only logs from the single server it's hard to say what's going on. For instance, a port scan can cause errors like, but so can normal operations over a bad network.
20160925 21:55:39-!- Bonobo [~Bonobo@2001:44b8:254:3200:a871:a299:2f8d:a76d] has joined #wesnoth-dev
20160925 22:01:51< celticminstrel> vultraz, EliDupree: The THoT bug mentioned was not a redraw issue.
20160925 22:02:45-!- louis94 [~~louis94@91.178.242.7] has joined #wesnoth-dev
20160925 22:02:59< celticminstrel> DeFender: regarding engine restrictions, spritesheets ARE possible with copious use of ~CROP.
20160925 22:03:00< celticminstrel> It might seem obvious that this would be horribly inefficient, but there is an image cache, so any given crop will theoretically only be calculated once. I'm not sure how much that helps though, and even with that it's presumably not very efficient.
20160925 22:03:21 * celticminstrel nots that the "DeFender" line was supposed to be a quote but somehow lost the timestamp.
20160925 22:03:24< celticminstrel> ^notes
20160925 22:05:00< tad_> celticminstrel: What THoT bug?
20160925 22:05:02< shadowm> You get both the spritesheet and the individual cropped bits in the cache.
20160925 22:05:32-!- gfgtdf [~chatzilla@x4e36ac7c.dyn.telefonica.de] has joined #wesnoth-dev
20160925 22:06:34-!- gfgtdf [~chatzilla@x4e36ac7c.dyn.telefonica.de] has quit [Client Quit]
20160925 22:07:53< celticminstrel> tad_: The standing animation one.
20160925 22:08:16< celticminstrel> shadowm: My point is that you get the individual cropped bits in the cache, yes.
20160925 22:08:31< celticminstrel> Of course, having those and the spritesheet isn't very space-efficient.
20160925 22:08:38< tad_> celticminstrel: Ah. It's in DiD too.  My guess is all campaigns show it
20160925 22:09:31< celticminstrel> tad_: This is the actual quote from vultraz I was responding to.
20160925 22:09:33< celticminstrel> [Sep 25@1:35:07pm] vultraz: thot s11, a change to the unit's variation didn't show on-screen despite [redraw]
20160925 22:09:41< celticminstrel> So probably not what you're thinking of with DiD.
20160925 22:10:11< tad_> celticminstrel: Ah. Fixed. Diff in my PR if someone needs it.
20160925 22:10:35< celticminstrel> Yeah, and my point was that it's not a redraw issue as vultraz had been implying.
20160925 22:10:42< celticminstrel> It's rather an animations issue.
20160925 22:11:26 * celticminstrel will quote EliDupree too for context and good measure.
20160925 22:11:27< celticminstrel> [Sep 25@1:32:32pm] EliDupree: Hmm. My Lua code is doing a series of costly operations that change a lot of terrain. My code is invoking wesnoth.fire ("redraw"), which works SOMETIMES, but eventually it freezes up and stops redrawing in a way that the user can see. Does anyone know why this is happening or what a good workaround might be?
20160925 22:11:29< celticminstrel> [Sep 25@1:33:21pm] EliDupree: (The operations do eventually finish and the final state becomes visible to the user, but it's no fun if they have to sit around staring at a static screen in the meantime)
20160925 22:11:30< celticminstrel> [Sep 25@1:33:49pm] vultraz: odd...
20160925 22:11:30< celticminstrel> [Sep 25@1:33:58pm] EliDupree: (The redraw occurs between each change and the next)
20160925 22:13:25< tad_> celticminstrel: The graphics bug I'm seeing now is all scenario and the effect varies but the usual is the unit only appears visibly when selected and the sidebar shows nothing ever. 
20160925 22:13:50< tad_> celticminstrel: other common appearences are standing units disappear for a frame or two on a regular heartbeat.
20160925 22:14:36< tad_> celticminstrel: And I have the commit # which seems to have caused the error but vultraz seems to prefer working to fix it rather than revert.
20160925 22:15:37< celticminstrel> tad_: This is the alpha commit?
20160925 22:15:46< tad_> celticminstrel: yep
20160925 22:15:49< celticminstrel> And still in latest master?
20160925 22:15:54< tad_> celticminstrel: yep
20160925 22:16:05< celticminstrel> Meaning the partial revert for ~O() doesn't fix it...
20160925 22:16:14 * tad_ shrugs
20160925 22:17:13< celticminstrel> I'm not sure if the surface copy constructor actually makes a copy of the surface.
20160925 22:17:49< celticminstrel> If it doesn't, I could see adjust_surface_alpha possibly being the problem here.
20160925 22:18:03< tad_> I took at stab at a revert two days ago when it appeared. After fixing the merge conflict and building the problem seemed gone. This afternoon I was happy just to get a clean build since it failed earlier in the day. Testing it and I see no change; alpha gliutches still there
20160925 22:47:36-!- mjs-de [~mjs-de@x4db64afe.dyn.telefonica.de] has quit [Remote host closed the connection]
20160925 22:50:25< DeFender> celticminstrel, yes, but the image cache will cache straight images just as well as CROPped ones.
20160925 22:52:29< shadowm> lol
20160925 23:47:36-!- louis94 [~~louis94@91.178.242.7] has quit [Ping timeout: 265 seconds]
20160925 23:48:51-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
--- Log closed Mon Sep 26 00:00:48 2016