--- Log opened Sun Aug 06 00:00:08 2017
20170806 00:03:14-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20170806 00:06:43-!- irker670 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20170806 00:13:06-!- zookeeper [zookeeper@wesnoth/developer/zookeeper] has quit [Ping timeout: 268 seconds]
20170806 00:19:13-!- celmin [~celticmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The minstrel departs, to spread the music to the masses!]
20170806 01:05:25-!- gfgtdf_ [~chatzilla@x4e32b54e.dyn.telefonica.de] has joined #wesnoth-dev
20170806 01:07:19-!- gfgtdf [~chatzilla@x4e36927e.dyn.telefonica.de] has quit [Ping timeout: 246 seconds]
20170806 01:07:21-!- gfgtdf_ is now known as gfgtdf
20170806 01:07:28-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has joined #wesnoth-dev
20170806 02:05:47-!- celmin [~celticmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20170806 02:18:55-!- gfgtdf [~chatzilla@x4e32b54e.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.93 [Firefox 54.0.1/20170628075643]]
20170806 03:42:38-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Quit: Leaving]
20170806 04:04:16< celmin> Sooooo I have certain hotkeys not working at all on master, at least with -t...
20170806 04:06:17< celmin> eg 'd' for unit description
20170806 04:25:05-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20170806 04:25:12-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20170806 04:41:25-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20170806 04:41:32-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20170806 05:23:57-!- JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] has joined #wesnoth-dev
20170806 05:33:25-!- Kwandulin [~Kwandulin@p200300E453C8F0402C6A6D82CC7B6E02.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170806 05:58:17-!- celmin [~celticmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The minstrel departs, to spread the music to the masses!]
20170806 06:03:33-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20170806 07:47:04-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170806 07:57:44-!- irker216 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20170806 07:57:44< irker216> wesnoth: Ignacio R. Morelle wesmere:develop e031e91b98c2 / wesmere/sass/mw/_wesnoth.scss: sass/mw: Declare dependency on the FA globe icon https://github.com/wesnoth/wesmere/commit/e031e91b98c26e69d655cddc8e35a5d2bd822fc0
20170806 07:57:46< irker216> wesnoth: Ignacio R. Morelle wesmere:develop 20d27cb9eadd / / (7 files in 3 dirs): static: New error document pages https://github.com/wesnoth/wesmere/commit/20d27cb9eadd275125aecc3a30b8483a9acd97c8
20170806 07:57:48< irker216> wesnoth: Ignacio R. Morelle wesmere:develop 47be5985dc3c / wesmere/sass/wmlunits.scss: sass/wmlunits: Initial version of the units.w.o stylesheet https://github.com/wesnoth/wesmere/commit/47be5985dc3cbcca5002acae881e7e1333897043
20170806 08:31:41-!- zookeeper [zookeeper@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20170806 08:33:09-!- DDR_ [~David@S0106f0f249839863.vc.shawcable.net] has quit [Ping timeout: 240 seconds]
20170806 09:27:07-!- Ravana_ [~Ravana@unaffiliated/ravana/x-2327071] has quit [Read error: Connection reset by peer]
20170806 09:28:13-!- Ravana_ [~Ravana@unaffiliated/ravana/x-2327071] has joined #wesnoth-dev
20170806 09:34:08-!- DDR_ [~David@S0106f0f249839863.vc.shawcable.net] has joined #wesnoth-dev
20170806 09:43:00< JyrkiVesterinen> All right. My plan to improve storyscreen performance is to implement caching for GUI canvas.
20170806 09:43:43< JyrkiVesterinen> The storyscreen just appends floating images to the canvas config, and the canvas redraws everything every time - over 50 images for the last frames.
20170806 09:44:12< JyrkiVesterinen> I plan to make it cache the earlier results, and only draw the new image, i.e. only one image at a time.
20170806 09:51:21-!- Ravana_ [~Ravana@unaffiliated/ravana/x-2327071] has quit [Read error: Connection reset by peer]
20170806 09:53:38-!- Ravana_ [~Ravana@unaffiliated/ravana/x-2327071] has joined #wesnoth-dev
20170806 09:56:38< vultraz_iOS> This should be interesting...
20170806 09:57:02< vultraz_iOS> Would apply to a_r too if you can make it work
20170806 10:07:45-!- Kwandulin [~Kwandulin@p200300E453C8F0402C6A6D82CC7B6E02.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20170806 10:19:10< DeFender1031> JyrkiVesterinen, yep, that's the issue, alright!
20170806 10:40:38< irker216> wesnoth: Jyrki Vesterinen wesnoth:master 6110fb59dbe8 / changelog players_changelog src/gui/core/canvas.cpp src/gui/core/canvas.hpp: GUI: implement canvas caching https://github.com/wesnoth/wesnoth/commit/6110fb59dbe8ffb226db720f1001aba76bdb4143
20170806 10:41:28< JyrkiVesterinen> I find the performance issue fully solved now. The cutscene appears smoother to me than in 1.12. :)
20170806 10:41:37-!- JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] has quit [Quit: Lunch time]
20170806 10:58:14-!- sevu [~Shiki@p54856149.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170806 11:05:42-!- Kwandulin [~Kwandulin@p200300E453C8F0402C6A6D82CC7B6E02.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170806 11:14:35< DeFender1031> JyrkiVesterinen, I would imagine so. Given the fix you describe, it could probably even do with a bit MORE granularity in terms of how many images it uses at this point. I'm gonna pull latest master and see how it looks now.
20170806 11:28:24< zookeeper> JyrkiVesterinen, so does it only cache one image (so, it draws the next image on the cached image, then draws the next on that, etc), or all intermediate steps? i'd imagine it must be the former or otherwise you'd fill the cache with 50 huge surfaces/textures, but you did say "earlier resultS", so just checking...
20170806 11:35:09< DeFender1031> zookeeper, I think the idea is that in the story screen context, each image gets added to the previous one anyway, so it just stores the "current image" and then blits whatever the new one is onto that, saves that as the new "current image", etc.
20170806 11:35:55< DeFender1031> It was the solution that I and several others suggested back when I first presented this little problem.
20170806 11:36:41< DeFender1031> And it'll help normal use-cases too (such as maps with things like {NEW_JOURNEY} and {NEW_BATTLE}
20170806 11:49:28< zookeeper> DeFender1031, certainly, and as said i'm pretty sure that's how he did it
20170806 12:05:19< DeFender1031> Right, I was clarifying that that's what I understood him to have meant.
20170806 12:06:47< DeFender1031> I think "earlier results" meant "Each result as we go" not "each result separately"
20170806 12:07:01< DeFender1031> But we can wait for Jyrki for confirmation.
20170806 12:07:07-!- david___ [~david@255.157.198.178.dynamic.wline.res.cust.swisscom.ch] has joined #wesnoth-dev
20170806 12:07:12< DeFender1031> In the meantime, my compile is done, so I get to see how it looks now...
20170806 12:07:44< DeFender1031> WOAH!
20170806 12:08:28< DeFender1031> Yeah, MUCH smoother than in 1.12.
20170806 12:08:43< DeFender1031> Also a little too fast of a fade now... gonna have to add a few more steps.
20170806 12:08:50< vultraz_iOS> I don't know now how to rectify this change with a_r :/
20170806 12:09:31< DeFender1031> Apparently 1.12 had a not-insignificant-but-short-enough-to-just-add-time-to-frames-and-not-actually-look-wrong amount of lag.
20170806 12:09:52< DeFender1031> vultraz_iOS, two scalpels and a sledgehammer?
20170806 12:10:08< vultraz_iOS> .............................................
20170806 12:10:17< vultraz_iOS> joke not appreciated
20170806 12:11:02-!- david___ [~david@255.157.198.178.dynamic.wline.res.cust.swisscom.ch] has quit [Quit: leaving]
20170806 12:11:07< DeFender1031> why do you have to take things so seriously all the time? you gotta learn to laugh about the challenges you're faced with or you'll burn yourself out from frustration.
20170806 12:12:44-!- JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] has joined #wesnoth-dev
20170806 12:13:33< vultraz_iOS> I dunno
20170806 12:13:38< vultraz_iOS> It just didn't land
20170806 12:14:06< JyrkiVesterinen> zookeeper: the cache only stores the cumulative state, i.e. one image.
20170806 12:16:13< DeFender1031> vultraz_iOS, so what you're saying is that it's not that you're taking thigs too seriously, it's that I'm just not as funny as I think I am. I can accept that. :P
20170806 12:20:17< zookeeper> JyrkiVesterinen, great
20170806 12:25:26-!- sevu [~Shiki@p54856149.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
20170806 12:29:56-!- http_GK1wmSU [~deep-book@119.81.19.251] has joined #wesnoth-dev
20170806 12:31:42-!- http_GK1wmSU [~deep-book@119.81.19.251] has left #wesnoth-dev []
20170806 12:41:50-!- Ravana_ [~Ravana@unaffiliated/ravana/x-2327071] has quit [Read error: Connection reset by peer]
20170806 12:42:33-!- Ravana_ [~Ravana@unaffiliated/ravana/x-2327071] has joined #wesnoth-dev
20170806 12:52:29-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20170806 12:52:36-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20170806 13:17:40-!- Bonobo [~Bonobo@203.220.138.162] has quit [Ping timeout: 260 seconds]
20170806 13:26:39-!- Kwandulin [~Kwandulin@p200300E453C8F0402C6A6D82CC7B6E02.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20170806 14:07:03-!- irker216 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20170806 14:30:33-!- sevu [~Shiki@p54856149.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170806 14:41:48-!- Kwandulin [~Kwandulin@p200300E453C8F0402C6A6D82CC7B6E02.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170806 14:43:29-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20170806 15:20:39-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20170806 15:20:45-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20170806 15:25:21-!- horrowind [~Thunderbi@p5B0D9A0A.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170806 15:45:12-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20170806 15:45:20-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20170806 16:33:29-!- sevu [~Shiki@p54856149.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
20170806 16:43:10-!- Kwandulin [~Kwandulin@p200300E453C8F0402C6A6D82CC7B6E02.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20170806 16:46:56-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has quit [Quit: Connection closed for inactivity]
20170806 17:24:56< shadowm> elias: wmlunits is *horribly* slow.
20170806 17:25:11< shadowm> On a desktop that's not doing anything else.
20170806 17:26:00< shadowm> And that's just during this stage: https://media.discordapp.net/attachments/318827821567049737/343806874572947466/Spectacle.NA8863.png?width=1104&height=509
20170806 17:26:41< celticminstrel> So does anyone have any idea what broke hotkeys all of a sudden?
20170806 17:27:18< celticminstrel> Mainly letter hotkeys, to be specific.
20170806 17:27:32< JyrkiVesterinen> Well, https://github.com/wesnoth/wesnoth/pull/1865 is the most obvious candidate...
20170806 17:27:47< celticminstrel> I thought you tested that.
20170806 17:28:10< JyrkiVesterinen> I did. In particular, I checked that using Ö as a hotkey works with a Finnish keyboard.
20170806 17:28:39< celticminstrel> Does that still work on master?
20170806 17:29:44< JyrkiVesterinen> Hold on, I'll rebuild and check. (Shouldn't take long, it's a partial rebuild.)
20170806 17:35:11< celticminstrel> On a sorta related note, does -t mess with the preferences? One or both of "don't save preferences" and "always use defaults".
20170806 17:35:40< celticminstrel> I suppose it's also possible that I killed it before it had a chance to save them, but I generally avoid killing it until the main window has been closed.
20170806 17:37:15< shadowm> -t is supposed to just launch the test scenario and set the game to quit upon finishing it.
20170806 17:38:19< celticminstrel> ` works at the title screen for me on master, but not in-game...
20170806 17:38:57< celticminstrel> It can't be my local changes, because I added a return to disable them...
20170806 17:42:55< JyrkiVesterinen> Okay, I tested ':', '.', 'A' and 'Ö'. They all work fine. All tested ingame with latest master.
20170806 17:44:41< celticminstrel> Huh.
20170806 17:55:57< celticminstrel> Hmm, I think I have an idea for Samonella's problem... add an "ignore_type_attacks" key or similar which specifies whether the attacks from the unit type are used when rebuilding the unit. This would also change the effect of embedding [attack] tags in [unit], allowing you to append to the unit's attacks rather than replacing them.
20170806 17:56:14< celticminstrel> (The default value of the key may depend on whether there are [attack] tags in the [unit] though? Not sure.)
20170806 17:56:17< celticminstrel> gfgtdf ^.
20170806 18:02:04< zookeeper> celticminstrel, i'm not even sure which problem you're referring to. the problem where not all attacks get removed, or the problem where direct modification to remove attacks doesn't persist?
20170806 18:03:53< zookeeper> err, wait a sec...
20170806 18:04:15< zookeeper> nevermind
20170806 18:08:26< shadowm> elias: I'm a bit puzzled at some of the markup going on in wmlunits tbh.
20170806 18:09:09< shadowm> And since you aren't even here I'm going to change some of it
20170806 18:11:25-!- irker075 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20170806 18:11:25< irker075> wesnoth: Ignacio R. Morelle wesnoth:wesmere-wmlunits 8bf57d6fe06f / data/tools/ (unit_tree/html_output.py wmlunits): wmlunits: Wire in Wesmere header and trailer https://github.com/wesnoth/wesnoth/commit/8bf57d6fe06f32dc3bbb42ad0a9b3ac164e0df1f
20170806 18:13:06-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170806 18:17:50-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170806 18:37:21< zookeeper> celticminstrel, so... what problem? i still don't know why you've diverged into the topic of what happens when rebuilding a unit.
20170806 18:39:55< zookeeper> AFAICT the only problem was that [modify_unit] [effect] apply_to=remove_attacks fails to remove all attacks even when it should
20170806 18:46:48-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 268 seconds]
20170806 19:07:39-!- matth1askrgr [matthiaskr@gateway/shell/panicbnc/x-owvsmpfswwifljvt] has joined #wesnoth-dev
20170806 19:07:44-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170806 19:07:59-!- Netsplit *.net <-> *.split quits: iwaim, matthiaskrgr
20170806 19:08:02-!- matth1askrgr is now known as Guest29263
20170806 19:11:09< celticminstrel> zookeeper: I was talking about the problem where nothing happens when he tries to remove all attacks with [effect].
20170806 19:12:44< celticminstrel> From what I can tell from what he's said, it just doesn't remove any attacks in the case where it should remove them all.
20170806 19:13:14-!- iwaim [~iwaim@rasteenie.alib.jp] has joined #wesnoth-dev
20170806 19:13:16-!- iwaim changed the topic of #wesnoth-dev to: 1.13.9 scheduled for sometime in August| Wesnoth Developers Channel | >>> Want to help? Go here: http://r.wesnoth.org/t42911 (and thanks!) <<< | Discord Server: https://discord.gg/tSmJS2E | Logs: http://irclogs.wesnoth.org | Bug tracker: http://bugs.wesnoth.org
20170806 19:13:16< celticminstrel> ...I wonder what happens though if he tries to remove the attacks in two stages (eg, first all melee attacks, then all ranged attacks). Do they end up with only the ranged attacks, or do they end up with all their attacks?
20170806 19:13:39< celticminstrel> ...what just changed in the topic?
20170806 19:13:56< celticminstrel> Looks pretty much the same to me?
20170806 19:14:15< celticminstrel> (BTW, regarding my hotkeys problem, I'm gonna try a full rebuild and see if that helps.)
20170806 19:15:05-!- travis-ci [~travis-ci@ec2-54-226-84-127.compute-1.amazonaws.com] has joined #wesnoth-dev
20170806 19:15:06< travis-ci> wesnoth/wesnoth#14626 (staging/wesmere-wmlunits - 8bf57d6 : Ignacio R. Morelle): The build passed.
20170806 19:15:06< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/261581576
20170806 19:15:06-!- travis-ci [~travis-ci@ec2-54-226-84-127.compute-1.amazonaws.com] has left #wesnoth-dev []
20170806 19:15:14< zookeeper> celticminstrel, https://forums.wesnoth.org/viewtopic.php?f=21&t=44570&start=30#p615946 <- can remove one/some attacks, but not all
20170806 19:15:58-!- ChipmunkV[m] [chipmunkvm@gateway/shell/matrix.org/x-xptibfrpojcqmpmk] has quit [Ping timeout: 240 seconds]
20170806 19:24:07-!- Guest29263 [matthiaskr@gateway/shell/panicbnc/x-owvsmpfswwifljvt] has quit [Changing host]
20170806 19:24:07-!- Guest29263 [matthiaskr@unaffiliated/matthiaskrgr] has joined #wesnoth-dev
20170806 19:24:07-!- Guest29263 [matthiaskr@unaffiliated/matthiaskrgr] has quit [Changing host]
20170806 19:24:07-!- Guest29263 [matthiaskr@gateway/shell/panicbnc/x-owvsmpfswwifljvt] has joined #wesnoth-dev
20170806 19:24:21-!- Guest29263 is now known as matthiaskrgr
20170806 19:35:04-!- gfgtdf [~chatzilla@x4e32b54e.dyn.telefonica.de] has joined #wesnoth-dev
20170806 19:35:07< gfgtdf> 20170806 17:55:57< celticminstrel> Hmm, I think I have an idea for Samonella's problem... add an "ignore_type_attacks" key or similar which specifies whether the attacks from the unit type are used when rebuilding the unit. This would also change the effect of embedding [attack] tags in [unit], allowing you to append to the unit's attacks rather than replacing them.
20170806 19:35:54< celticminstrel> Yes?
20170806 19:36:55< gfgtdf> celticminstrel: first, the 'base' that is changes is not the type but the type with applied applied modification of that unit. Not sure what would be ba better name though
20170806 19:37:18< gfgtdf> celticminstrel: i also sont think the part with appending nstead of replacing would be a good idea
20170806 19:38:25< celticminstrel> Why not?
20170806 19:39:19< gfgtdf> celticminstrel: you'd rareley want that, The prblem here is stoing+unstoring you sureley don't want the units to ahev all attacks twice after store+unstore
20170806 19:39:40< celticminstrel> That's true, but I don't think that would happen.
20170806 19:39:52< celticminstrel> Unstoring a unit is equivalent to creating a new unit that replaces the old, isn't it?
20170806 19:40:01< gfgtdf> celticminstrel: yes
20170806 19:40:18< celticminstrel> So it would be appending those attacks to the base unit of type+modifications, not to what the unit already had.
20170806 19:40:32< celticminstrel> A store/unstore could be thought of as rebuilding the unit, in fact?
20170806 19:40:55< gfgtdf> celticminstrel: yes bug the attacks it's be appending are exactly the attacks of tpye+modifications in the default case.
20170806 19:41:38< celticminstrel> True, so you'd need append to be a special case.
20170806 19:42:29< celticminstrel> And it would probably just apply at creation, and be flipped back once the attacks are appended so that store/unstore doesn't double them as you say.
20170806 19:42:40< zookeeper> so if i may ask, how does this relate to his problem?
20170806 19:42:58< zookeeper> why does [modify_unit] [effect] work differently than [object] [effect]?
20170806 19:43:05< gfgtdf> celticminstrel: sine you can already eiasly do so via [effect] (in [object] which is also more save since the attacks arent lost when the unit is rebuild (as it happen for exampel in [remove] object)) i dont think ther ei ned to add sucha  feature.
20170806 19:43:19< celticminstrel> [modify_unit] stores and unstores the unit.
20170806 19:43:38< gfgtdf> zookeeper: because  [modify_unit] [effect] applied the effect witohut sotign it in the units [modifications]
20170806 19:43:48< celticminstrel> You do have a point about this already being possible with [object], though.
20170806 19:43:58< gfgtdf> zookeeper: you can ofc use  [modify_unit][object][effect]
20170806 19:44:22< celticminstrel> So wait, is Samonella actually just doing something wrong then?
20170806 19:44:32< celticminstrel> Or is there an actual bug? I'm confused now.
20170806 19:47:19< gfgtdf> celticminstrel: well both, i mean in any case  Samonella  shodul rprobably use [modify_unit][object][effect] or just [object][effect], still i still think that storing+unsotring without any variable manipulation shoudl not change the unit.
20170806 19:48:04< celticminstrel> I think I'd agree on that, yeah.
20170806 19:48:26< zookeeper> gfgtdf, i still don't see why that causes removal of all attacks to fail
20170806 19:48:55< celticminstrel> I was assuming that the lack of any attacks in the unit config causes the game to automatically fill it in with the unit type's default attacks.
20170806 19:49:28< gfgtdf> zookeeper: becasue Samonella  (oe rprobalby the  [modify_unit] does a sotre+unstore (even though wthout any vriable maipuilation))
20170806 19:50:02< celticminstrel> Looks like Samonella just confirmed my theory.
20170806 19:50:15< celticminstrel> So I think adding a key something like what I described would fix it, then.
20170806 19:50:18< zookeeper> gfgtdf, still doesn't make any sense to me
20170806 19:50:29< gfgtdf> zookeeper: hmm ok i'll open a pr
20170806 19:50:30< celticminstrel> And storing the unit sets that key to true if the unit has no attacks, or something.
20170806 19:50:35< gfgtdf> issue i meant
20170806 19:50:48-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20170806 19:52:49< irker075> wesnoth: Ignacio R. Morelle wesnoth:wesmere-wmlunits 416e3b547993 / data/tools/unit_tree/html_output.py: wmlunits: First markup clean-up pass https://github.com/wesnoth/wesnoth/commit/416e3b5479934e97527aa9211b37080e8ce184c6
20170806 19:53:31< irker075> wesnoth: Ignacio R. Morelle wesmere:develop c9c8c0cac663 / wesmere/sass/wmlunits.scss: sass/wmlunits: Finish "overview" styles, some cleanup/changes elsewhere https://github.com/wesnoth/wesmere/commit/c9c8c0cac663a58be7c467e6ddc48ef98ca695b3
20170806 19:54:18< zookeeper> gfgtdf, i understand that if [modify_unit][effect] doesn't write the effects into unit.modification then the removed attacks get restored on unstore, but that doesn't explain why it only restores one attack and not all. which was his problem.
20170806 19:55:11-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20170806 19:55:13< gfgtdf> zookeeper: i think you misundersood his problem, iirc he said it works when he removes all but one attacks, but it doesn't when all attacks are removed.
20170806 19:56:32< zookeeper> well, again: https://forums.wesnoth.org/viewtopic.php?f=21&t=44570&start=30#p615946 <- i think that's fairly unambiguous
20170806 19:56:55< zookeeper> (assuming that he's correct in the first place, naturally)
20170806 19:58:27< gfgtdf> zookeeper: hmm i'd ahve to test i before i believe it
20170806 20:01:03< gfgtdf> zookeeper: hmm no i just tested and removing all attacsk brings all attacks back, evne if the unit has more attacks
20170806 20:01:28< gfgtdf> (in AoI i did 'lua wesnoth.wml_actions.modify_unit {  T.filter {}, T.effect { apply_to="remove_attacks"}}')
20170806 20:01:40< gfgtdf> side1 leader still had all his attacks
20170806 20:06:57< zookeeper> hmh, yeah
20170806 20:10:14< zookeeper> okay, so, i guess he was just mistaken about that part
20170806 20:10:28< zookeeper> which makes this a whole lot simpler
20170806 20:11:23-!- gfgtdf [~chatzilla@x4e32b54e.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.93 [Firefox 54.0.1/20170628075643]]
20170806 20:12:51< zookeeper> that [modify_unit][effect] simply applies the changes without any concern for persistence doesn't strike me as wrong as such, it might even be the intended behaviour (of course, if so then it's documented badly). hard to say much without knowing who added it and why and whether this issue was actually considered.
20170806 20:16:55< zookeeper> maybe someone added it without thinking about it, or maybe they added it with the intent that one should only use it when they know what they're doing and just "forgot" to document it as such.
20170806 20:19:21< zookeeper> it might have been intentionally added as a way to modify the unit using EffectWML but without causing every change to permanently pile up in unit.modifications (unless manually cleared)
20170806 20:37:38< irker075> wesnoth: Ignacio R. Morelle wesnoth:wesmere-wmlunits d0c43b89c46e / data/tools/unit_tree/ (html_output.py overview.py): wmlunits: SEO-friendly page titles, and extra root element classes https://github.com/wesnoth/wesnoth/commit/d0c43b89c46e2603c79427502aad8327d0d58dd6
20170806 20:37:41< irker075> wesnoth: Ignacio R. Morelle wesnoth:wesmere-wmlunits e9287e5b6be6 / data/tools/unit_tree/ (html_output.py overview.py): wmlunits: Rechristening Overview as the Build Report, table structure cleanup https://github.com/wesnoth/wesnoth/commit/e9287e5b6be6b965560808e2fd59efcd794b4c96
20170806 20:40:11-!- horrowind [~Thunderbi@p5B0D9A0A.dip0.t-ipconnect.de] has quit [Quit: horrowind]
20170806 20:41:07-!- horrowind [~Thunderbi@p5B0D9A0A.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170806 20:41:19-!- horrowind [~Thunderbi@p5B0D9A0A.dip0.t-ipconnect.de] has quit [Client Quit]
20170806 20:41:55-!- horrowind [~Thunderbi@p5B0D9A0A.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170806 20:53:58-!- JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] has quit [Quit: .]
20170806 21:17:35-!- ChipmunkV[m] [chipmunkvm@gateway/shell/matrix.org/x-naphuumhautpyjil] has joined #wesnoth-dev
20170806 21:22:53-!- gfgtdf [~chatzilla@x4e32b54e.dyn.telefonica.de] has joined #wesnoth-dev
20170806 21:29:22< gfgtdf> zookeeper: iirc [modify_unit][effect] as explicitly added to have this behaviour an it replaced the '[object] mo_write=' flag which we had temporaily in 1.13+dev
20170806 21:29:42< zookeeper> right
20170806 21:30:24< gfgtdf> zookeeper: still in 90% of cases you don't want non-persistent changed. so what you usualyl want is [modify_unit][object][effect]
20170806 21:45:08-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20170806 21:45:14-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20170806 21:50:12< zookeeper> yeah, so there's basically no problem at all
20170806 21:51:29< zookeeper> (assuming that he was actually mistaken about only one attack getting removed/restored)
20170806 21:52:00< gfgtdf> zookeeper: well there is the problem that storing+unstore readds all attacks if they were previosuly removed via unpersistant actions.
20170806 21:52:29< zookeeper> that's more like a missing non-essential feature
20170806 21:53:05< gfgtdf> zookeeper: you might think it was always like that, but the point is that before it was also not possbile to remvoe attacks via unpersistant acions
20170806 21:55:09< zookeeper> a point for what?
20170806 21:55:25< zookeeper> i can believe that it was not possible to remove attacks via unpersistant actions before
20170806 21:57:17< gfgtdf> zookeeper: that's why 'unstore unit removed unpersistent actions' was not really a problem before.
20170806 21:58:24-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20170806 21:58:48< zookeeper> are you talking about the time when you could {CLEAR_VARIABLE unit.attack} and that _was_ persistent?
20170806 21:59:10< gfgtdf> zookeeper: no i don't remember that time.
20170806 21:59:28< gfgtdf> before= 1.12
20170806 22:00:36< zookeeper> ok, well, in that case i still have no idea what you're arguing for or against
20170806 22:01:02< gfgtdf> zookeeper: you said the current behvaiour is not really a bug.
20170806 22:01:35< zookeeper> yeah, i think it clearly seems like intended behaviour
20170806 22:01:39< gfgtdf> i say if the code `[store_unit]+ [unstore_unit]` unexpectedly adds attacks to a unit even tough the stored variable was not modified at all, then that's clearly a bug.
20170806 22:02:33< gfgtdf> in fact you mostlikeley don'T even need to use any wml, just saveing+reloading the game will probably remvoe the attacks aswell.
20170806 22:02:46< zookeeper> can that actually happen?
20170806 22:03:13< gfgtdf> from looking at the code i'd say yes.
20170806 22:03:22< zookeeper> how do you remove the attacks from the unit before [store_unit] in such a way that they don't get readded?
20170806 22:03:57< celticminstrel> ...hotkeys still not working for me, even with a full rebuild and no local changes...
20170806 22:04:17< gfgtdf> zookeeper: with wesnoth.add_modification.( .... ,false)
20170806 22:04:20< celticminstrel> Or rather, text-like hotkeys.
20170806 22:04:26< celticminstrel> eg alt-R works but R does not.
20170806 22:04:42< celticminstrel> I guess... I'll have to do a bisect...?
20170806 22:05:43< gfgtdf> celticminstrel: any thought on makting `T` (T = helper.set_wml_tag_metatable {}) defined in wesnoths global lua files ?
20170806 22:06:02< celticminstrel> I don't really see a point.
20170806 22:06:08< zookeeper> gfgtdf, if that's the only way, wouldn't it make sense to make wesnoth.add_modification do a rebuild of the unit just like unstoring does?
20170806 22:06:34< gfgtdf> zookeeper: no rebuilding is inceldibly slow
20170806 22:06:56< celticminstrel> Actually gfgtdf, it's already in core.lua as wml.tag
20170806 22:07:18< celticminstrel> So you can now do local T = wml.tag instead of local T = helper.set_wml_tag_metatable{}
20170806 22:07:43< celticminstrel> I don't see much point in adding T there as well.
20170806 22:07:51< gfgtdf> zookeeper: also it'D reult in endledd loops as add_modiflycation is epxlicoitly used for example when defiuning modifications
20170806 22:08:14< gfgtdf> it'd result in endless
20170806 22:08:17< zookeeper> gfgtdf, right.
20170806 22:08:19< gfgtdf> when defining custom effects
20170806 22:10:02< gfgtdf> celticminstrel: this is onyl slightly less to type
20170806 22:10:38< celticminstrel> I'll also add that I think core.lua shouldn't put too much stuff in the global namespace.
20170806 22:10:57< zookeeper> i mean, i think that since we do have the behaviour of unit data getting restored based on the unit type data, such as when attacks are removed via direct modification, then it makes sense to perform that uniformly everywhere. it gets awfully messy if there's one path of direct modification that is able to avoid that, since as you said it leads to a situation where it will sooner or later 
20170806 22:10:57< zookeeper> happen to the unit anyway.
20170806 22:13:40< gfgtdf> zookeeper: well the aim shodul ofc be that it will not happen sonner or later anyweays and that the 'fix' shoudl apply to both save+reload and manual storing/unstoring
20170806 22:13:59< zookeeper> well do you have a suggestion for a fix?
20170806 22:14:53< gfgtdf> zookeeper: the most simply idea woudl be to make store_unit add a don_trestore_attacks=yes keys to the stored unit that'd need to be eplxcitly removed to make the engine read all attacks
20170806 22:14:58< gfgtdf> simple*
20170806 22:16:35< zookeeper> uhm
20170806 22:19:13< zookeeper> 1) why would you make a hack specific to attacks only?, 2) it'd screw over the guy who wants to restore attacks on unstore instead of the guy who wants it to not happen (why?)
20170806 22:20:09< celticminstrel> Regarding 2, if the presence of that key is part of the stored unit, then someone wanting to restore the attacks need only remove it.
20170806 22:20:47< zookeeper> yeah, and similarly the key could just be restore_attacks=no and then the someone who wants to not restore attacks needs only to add it
20170806 22:21:00< gfgtdf> zookeeper: becasue other tags, liek abilitites are stored ina  container tag, for eability theres is a difference between 'no abilitites tag'(=readd abilitites) and 'no abiltites tag'(=oberverite unit abiltites with this empty tag) with issues is realyl wpcific to attacks
20170806 22:21:21< gfgtdf> zookeeper:  no that wouldnt fix the bug here
20170806 22:21:32< celticminstrel> Yeah, so the question is, which behaviour is more unexpected?
20170806 22:21:45< celticminstrel> IMO, it's more unexpected for the attacks to suddenly reappear.
20170806 22:24:12< zookeeper> well, i think it's only unexpected if you frame it as "i tried to remove attacks, but they reappeared - that's confusing!". if instead you describe it as "if you clear things then they get re-added based on the unit type data, so you can always get rid of all direct modifications that way... except for attacks, there the default is to not do that and instead you have to use a special toggle 
20170806 22:24:12< zookeeper> to prevent it"...
20170806 22:24:50< zookeeper> gfgtdf, i'm not following
20170806 22:26:04< gfgtdf> zookeeper: having itr efault to not woudl imply just the same bahiour as previosuly be default
20170806 22:26:09< gfgtdf> it defult to false
20170806 22:27:58< gfgtdf> zookeeper: also aboiut storing+unstore unit. It is usualyl complatley unlreated to attacks and the dev will usually not  think like 'oh i am using unstore unit, will this mess up my unit attacks?', if you for exampel store a unit to change its position or its side and it as aside effect readds attacks this is just unexpeted, 
20170806 22:28:43< zookeeper> having it default to false would imply just the same behaviour as now. is that what you meant?
20170806 22:29:00< gfgtdf> zookeeper: yes
20170806 22:29:34< zookeeper> okay. is there a problem with having that as the default? it makes more sense to me because then attacks are treated the same as everything else; if missing, they get re-added.
20170806 22:30:02-!- Coffee_irc [~david@203.220.138.162] has quit [Quit: Konversation terminated!]
20170806 22:30:25< zookeeper> and yes i completely agree that a simple store+unstore should not result in changes. which is why i suggested that wesnoth.add_modification should not provide the loophole it apparently currently does
20170806 22:30:43< gfgtdf> zookeeper: you didn't suggest a solution.
20170806 22:31:13< gfgtdf> zookeeper: i mena yes, don't us add moficfication with attacks like that.
20170806 22:32:51< zookeeper> my first solution would be to close the loopholes, and make anything that is able to clear things (such as attacks) from a unit perform the-thing-that-readds-missing-stuff-from-unit-type. but you said it's slow.
20170806 22:34:11< zookeeper> is the slowness actually a problem? i mean, it means that [modify_unit] and [unstore_unit] are slow too, but people rarely complain about their speed.
20170806 22:35:28< gfgtdf> celticminstrel: any opinion on chageing add_moffications interface? the 'problem' is that even tough you ahev false as 3. parmeter you still have to specify the unless 1 parameter
20170806 22:35:47< gfgtdf> celticminstrel: do my idea way to make just that the modification don'T get added if you simply leave out the first parameter
20170806 22:35:51< gfgtdf> don't
20170806 22:36:28< gfgtdf> zookeeper: i do complain a lot about their speed :). also it's still the problem with the infinite loops.
20170806 22:37:21< zookeeper> right, the loop
20170806 22:38:15< zookeeper> i dunno, you're the technician here. any ideas how to avoid that? :P
20170806 22:39:56< gfgtdf> celticminstrel: useless* 1 parameter
20170806 22:40:12< gfgtdf> celticminstrel: so* my idea was*
20170806 22:41:17< gfgtdf> zookeeper: hmm no ia also dont' think this is the corrently way to fix it, also it's probably break even more addons than the don_trestore_attacks attribute
20170806 22:41:44-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20170806 22:43:53< celticminstrel> zookeeper: I still think it's more surprising for data to reappear than it is for things to stay exactly how you left them.
20170806 22:44:39< celticminstrel> (And I doubt the unit rebuild is super-slow; it may not be highly efficient, but I wouldn't expect the slowness to be significant.)
20170806 22:45:15< celticminstrel> gfgtdf: So can you give an example of how you'd use it in the current way and in your proposed way?
20170806 22:47:39< gfgtdf> celticminstrel: https://pastebin.com/yhcVCiXA
20170806 22:48:55< gfgtdf> celticminstrel: when i played LotI (i also cheated to need less exp to get more advancements) i had units that took 1/4 second to unstore
20170806 22:49:52< zookeeper> celticminstrel, no one's suggesting that things should not stay exactly how you left them
20170806 22:50:16< gfgtdf> celticminstrel: in fact when i tried to optimize the loti code it all went down to minimizing the amount to unstore_unit calls.
20170806 22:52:35< celticminstrel> I see.
20170806 22:52:42< zookeeper> gfgtdf, there's 3 add-ons with a match for "add_modification"
20170806 22:52:55< celticminstrel> That new method seems fine to me.
20170806 22:53:14< celticminstrel> Was there only one optional boolean? I can't remember.
20170806 22:53:27< gfgtdf> zookeeper: [object] also uses add_modification
20170806 22:53:57< celticminstrel> BTW, we should probably consider trying to rewrite [modify_unit] to not store/unstore.
20170806 22:54:08< zookeeper> gfgtdf, so how might my suggestion change [object] behaviour?
20170806 22:54:51< gfgtdf> zookeeper: well you suggested to rebuidl the unit when an object is added
20170806 22:55:11< gfgtdf> (whcih is what add_modifcation) usualyl does
20170806 22:55:25< zookeeper> units are not currently rebuilt when an object is added?
20170806 22:55:38< gfgtdf> zookeeper: no
20170806 22:55:38< celticminstrel> I don't think units are rebuilt when an object is added.
20170806 22:55:43< celticminstrel> Only when one is removed.
20170806 22:55:44< zookeeper> huh, okay.
20170806 22:59:39< zookeeper> but... i don't see how that would cause my suggestion to change [object] behaviour.
20170806 23:00:14< gfgtdf> zookeeper: well i'T mean that [object] woudl remove all modifications done to a unit via direct variable manipulation.
20170806 23:00:33< zookeeper> oh, duh
20170806 23:00:34< zookeeper> yeah
20170806 23:00:47< zookeeper> oh, wait, no
20170806 23:01:00< zookeeper> because you couldn't have any direct modifications by the time you apply the object
20170806 23:02:05< gfgtdf> zookeeper: why that ? just use store_unit, then variable manuplation, then unstore, and then [object]
20170806 23:02:19< zookeeper> unstore would readd the attacks
20170806 23:02:53< gfgtdf> yes but direct varialbe manuplation is more then just attacks.
20170806 23:03:09< gfgtdf> you coudl change the units max_hp and object woudl thne undo that
20170806 23:03:20< gfgtdf> would then*
20170806 23:03:38< zookeeper> does unstoring cause a rebuild?
20170806 23:04:34< gfgtdf> zookeeper: yes but it overwrites it with the given attrobutes afterwards
20170806 23:04:57< zookeeper> what given attributes?
20170806 23:05:06< gfgtdf> the ones in the variable that was unstored
20170806 23:06:43< zookeeper> okay. so couldn't that happen with object too?
20170806 23:08:13< gfgtdf> zookeeper: so you are baiscalyl sugessting run a complare reuild, then overwriting all stuff, just to make it add attacks?
20170806 23:12:18< zookeeper> i don't know, maybe? i can't follow the whole train of thought needed to answer that
20170806 23:23:08< zookeeper> i think i've pretty much exhausted my mental capacity for tonight
20170806 23:27:35< zookeeper> but if i'd sum up my suggestion as "don't allow any way of modification that would cause a subsequent store+unstore or dummy object to result in said modifications to be lost", then the main problem would be that it'd make several things a lot slower?
20170806 23:30:19< zookeeper> (well, the infinite loop too)
20170806 23:31:12< celticminstrel> So any ideas about how difficulty it might be to rewrite [modify_unit] to not store/unstore?
20170806 23:31:42< celticminstrel> IMO, using store/unstore to change a unit is not ideal; it's better used for storing units away to bring them back later.
20170806 23:31:59< zookeeper> anyway, seems like a hairy situation either way, since special behaviour for missing attacks is pretty iffy too. i never asked what makes attacks so special compared to max_hitpoints or [resistance] or whatever because that felt like a distraction at the time.
20170806 23:32:31< zookeeper> i'm off to bed for now, maybe i'll receive some kind of enlightenment ->
20170806 23:37:15-!- zookeeper [zookeeper@wesnoth/developer/zookeeper] has quit [Ping timeout: 268 seconds]
20170806 23:45:27-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20170806 23:55:57< irker075> wesnoth: Ignacio R. Morelle wesmere:develop a05b8a1cdb67 / wesmere/sass/wmlunits.scss: sass/wmlunits: Downscale unit images proportionally and only on the units tree https://github.com/wesnoth/wesmere/commit/a05b8a1cdb67cb7a7f2b02e633d4d9df0310bcec
--- Log closed Mon Aug 07 00:00:09 2017