--- Log opened Thu Mar 15 00:00:27 2018
20180315 00:00:29< vultraz> celticminstrel: so, are we going to merge the dunefolk stuff for 1.13.12?
20180315 00:01:02< celticminstrel> I hope so.
20180315 00:01:06< celticminstrel> That was the idea.
20180315 00:01:22< celticminstrel> I'd suggest trying to point some MP people towards it.
20180315 00:01:50< celticminstrel> And, I'd say, as long as there are no objections within, say, a week, then it could be merged.
20180315 00:05:36-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20180315 00:08:20-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20180315 00:13:33< celticminstrel> vn9711: Do you plan to document these based on comments, or are you asking for us to do so?
20180315 00:13:58< celticminstrel> (The former would presumably require looking at source code and/or actual uses of them.)
20180315 00:15:15 * celticminstrel focused on the ones that gfgtdf was unsure of or didn't know.
20180315 00:16:11< gfgtdf> i made crossed in the original post where the functions are already docuemented but have no linsk in the main luawml page
20180315 00:17:07< celticminstrel> I wish you'd also used a list instead of code tags in your explanation post, it would've been much easier to read.
20180315 00:21:54< celticminstrel> vultraz: FTR, the person who suggested the changes seems to approve.
20180315 00:22:12< celticminstrel> (On the forum thread)
20180315 00:28:36< shadowm> The word is still "either" and not "eigher" (which is not a word), by the way.
20180315 00:28:53< shadowm> (The person this is meant for know who they are.)
20180315 00:33:04< celticminstrel> vultraz: I'd also like to note that I didn't test the dunefolk PR at all, though the fact that it passed Travis (at least on the first run) is probably an indication that it's fine in that regard.
20180315 01:06:25-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20180315 01:16:08-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20180315 01:17:13< irker201> wesnoth: Charles Dang wesnoth:master a023c7989ea8 / / (6 files in 3 dirs): New Elvish Sylph baseframe by Jetrel (@rkettering) https://github.com/wesnoth/wesnoth/commit/a023c7989ea82e7405b4d73d16951a50c0a3630b
20180315 02:13:32< celticminstrel> :O
20180315 02:15:56< vultraz> It's been around for years, just never committed
20180315 02:16:12< celticminstrel> I knew that.
20180315 02:16:32< celticminstrel> Doesn't seem the best time to commit it though.
20180315 02:16:37< vultraz> why
20180315 02:16:38< vultraz> ?
20180315 02:16:42< celticminstrel> Because it's not animated.
20180315 02:17:00< vultraz> Neither way the other one
20180315 02:17:02< vultraz> was
20180315 02:17:25< celticminstrel> It was more animated than this one?
20180315 02:17:37< celticminstrel> Is there a new shyde, too?
20180315 02:17:56< celticminstrel> I guess reaching animation par with the old sylph is actually doable before release though.
20180315 02:18:13< celticminstrel> Since that's just two more frames needed.
20180315 02:18:17< vultraz> 3
20180315 02:18:31< vultraz> and yes
20180315 02:18:32< vultraz> https://www.wesnoth.org/jetrel/Wesnoth/elf-archer-comp.png
20180315 02:18:33< celticminstrel> Three total, yes. There's one already, so two more.
20180315 02:18:36< vultraz> but it's jus a baseframe
20180315 02:18:55< celticminstrel> So yeah, committing the new shyde is something better done for 1.15 then.
20180315 02:19:10< vultraz> I mean, I'm not opposed to throwing out all the animations
20180315 02:19:13< celticminstrel> Ah, wait, I misunderstood.
20180315 02:19:17< celticminstrel> You're right, it's three more.
20180315 02:19:32< celticminstrel> I read that as three deletes and an add for some reason, when it's actually three deletes and an edit.
20180315 02:21:04< celticminstrel> Doesn't mountains=60 mean 40% defense?
20180315 02:21:52< vultraz> i think so?
20180315 02:24:54< irker201> wesnoth: Celtic Minstrel wesnoth:dunefolk_balance 19fbd125c9be / data/core/units/dunefolk/ (Marauder.cfg Raider.cfg): Attempt to address RIPLIB violations in Raider -> Marauder advancement https://github.com/wesnoth/wesnoth/commit/19fbd125c9bec09e88910af99bec8d95454b07f0
20180315 02:41:44-!- Bonobo [~Bonobo@61.68.89.80] has quit [Ping timeout: 260 seconds]
20180315 02:42:17-!- gfgtdf_ [~chatzilla@x4e363044.dyn.telefonica.de] has joined #wesnoth-dev
20180315 02:45:21-!- gfgtdf [~chatzilla@x4e3630de.dyn.telefonica.de] has quit [Ping timeout: 264 seconds]
20180315 02:45:25-!- gfgtdf_ is now known as gfgtdf
20180315 02:50:25-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20180315 02:50:32-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20180315 03:00:17< celticminstrel> I'm confused now. Where the heck does the schema validator actually look up links? :|
20180315 03:00:51< celticminstrel> find_tag() checks them, but the validator just calls tags() which returns only the non-linked tags...
20180315 03:02:57< vultraz> links() ?
20180315 03:03:23< celticminstrel> Ohh, invalid tags are checked for in open_tag(), not validate().
20180315 03:03:32< celticminstrel> Yeah, links() returns the links, but validate never even looks at that.
20180315 03:03:49< celticminstrel> Okay, so basically I need to make find_tag() also look at all the conditionals.
20180315 03:14:39< celticminstrel> Ugh, that's... maybe not such a good idea... :|
20180315 03:16:20< celticminstrel> It does work, though, but there's one little annoying caveat which is that find_tag() is called in one place where you actually don't have a config to match it against.
20180315 03:18:27< celticminstrel> (It's called when expanding super-tags.)
20180315 03:19:44< celticminstrel> ATM I'm passing an empty config there, but I have a feeling that this'll create problems in some cases...
20180315 03:20:10< celticminstrel> The conditions in [effect] are such that an empty config can never match, so any issues won't show themselves at this point.
20180315 03:20:33< celticminstrel> But what if you have a condition of eg [not]thing=sruff?
20180315 03:20:39< celticminstrel> ^stuff
20180315 03:21:05< celticminstrel> ...oh wait.
20180315 03:21:56< celticminstrel> ...no never mind. (I was noticing that thing=stuff requries the thing key to exist to match, but... the [not] literally means it matches if its contents don't so... the key wouldn't even need to exist at all for that to match.)
20180315 03:22:11< celticminstrel> So basically in that case the super-tag would be incorrectly expanded...
20180315 03:22:43< celticminstrel> I guess I could make the system never match an empty config?
20180315 03:23:02< celticminstrel> That might be sufficient. Will try it.
20180315 03:26:02-!- TC01 [~quassel@venus.arosser.com] has quit [Remote host closed the connection]
20180315 03:30:44-!- Bonobo [~Bonobo@129.127.113.21] has joined #wesnoth-dev
20180315 04:06:17< irker201> wesnoth: Charles Dang wesnoth:master e3d136de7674 / data/core/images/units/elves-wood/sylph.png: Updated new Sylph sprite to the new Elvish palette https://github.com/wesnoth/wesnoth/commit/e3d136de76741bd229efd41e29a7c244d9972698
20180315 04:07:00< vultraz> V I B R A N T 
20180315 04:13:33< vultraz> celticminstrel: is it deliberate that terrain masks don't seem to override starting positions?
20180315 04:19:37< irker201> wesnoth/wesnoth:master Jyrki Vesterinen 2c6a6e61d3 Fix build AppVeyor: All builds passed
20180315 04:20:03< celticminstrel> I have no idea.
20180315 04:20:14< celticminstrel> Might be.
20180315 04:21:38< celticminstrel> But it's late and I need to sleep and thus can't think on it right now.
20180315 04:21:59< celticminstrel> I'd hoped to push the next schema commit today, but I guess that won't happen.
20180315 04:22:18-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20180315 04:22:41-!- gfgtdf [~chatzilla@x4e363044.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.93 [Firefox 52.7.0/20180307131617]]
20180315 04:33:21-!- Bonobo [~Bonobo@129.127.113.21] has quit [Ping timeout: 264 seconds]
20180315 04:39:51< irker201> wesnoth/wesnoth:master pentarctagon b6fb5837c3 Explicitly link to ICU libraries for Lin AppVeyor: All builds passed
20180315 05:01:25-!- JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] has joined #wesnoth-dev
20180315 05:19:40-!- JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] has quit [Quit: .]
20180315 06:38:08< vn9711> (got a 50 second disconnection today too, 6 minutes ago.)
20180315 07:07:59< irker201> wesnoth: pentarctagon wesnoth:master 562350bae221 / src/CMakeLists.txt: Explicitly link to ICU libraries for Linux. https://github.com/wesnoth/wesnoth/commit/562350bae2212ac7d138920814ee7af1b91139ac
20180315 07:19:54-!- JyrkiVesterinen [~JyrkiVest@195-192-251-124.s1networks.fi] has joined #wesnoth-dev
20180315 07:25:19-!- travis-ci [~travis-ci@ec2-54-205-141-74.compute-1.amazonaws.com] has joined #wesnoth-dev
20180315 07:25:19< travis-ci> wesnoth/wesnoth#16911 (master - 562350b : pentarctagon): The build is still failing.
20180315 07:25:19< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/353692399
20180315 07:25:19-!- travis-ci [~travis-ci@ec2-54-205-141-74.compute-1.amazonaws.com] has left #wesnoth-dev []
20180315 07:27:42< irker201> wesnoth: Jyrki Vesterinen wesnoth:master 2fc45ba12d97 / src/CMakeLists.txt: Simplify "is targeting GNU/Linux" check https://github.com/wesnoth/wesnoth/commit/2fc45ba12d9755ece0a0af2d218448ea9e70515e
20180315 07:33:12-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 246 seconds]
20180315 07:43:29-!- travis-ci [~travis-ci@ec2-54-159-252-155.compute-1.amazonaws.com] has joined #wesnoth-dev
20180315 07:43:30< travis-ci> wesnoth/wesnoth#16912 (master - 2fc45ba : Jyrki Vesterinen): The build is still failing.
20180315 07:43:30< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/353697476
20180315 07:43:30-!- travis-ci [~travis-ci@ec2-54-159-252-155.compute-1.amazonaws.com] has left #wesnoth-dev []
20180315 08:05:30< irker201> wesnoth/wesnoth:master Celtic Minstrel 552488e56e Attempt to address RIPLIB violations in  AppVeyor: All builds passed
20180315 08:11:47< irker201> wesnoth: Charles Dang wesnoth:master fb61666e9605 / src/build_info.cpp: Fixup build https://github.com/wesnoth/wesnoth/commit/fb61666e960521f431f34a641b57906954b807eb
20180315 08:31:26< vultraz> zookeeper: quick question: how come certain units specify their baseframe as the last frame of the attack anim?
20180315 08:31:53-!- travis-ci [~travis-ci@ec2-54-234-144-117.compute-1.amazonaws.com] has joined #wesnoth-dev
20180315 08:31:54< travis-ci> wesnoth/wesnoth#16913 (master - fb61666 : Charles Dang): The build is still failing.
20180315 08:31:54< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/353709932
20180315 08:31:54-!- travis-ci [~travis-ci@ec2-54-234-144-117.compute-1.amazonaws.com] has left #wesnoth-dev []
20180315 08:32:30< JyrkiVesterinen> Good, we're down to the XCode build now.
20180315 08:33:34< zookeeper> vultraz, because whoever wrote it thought it looks nicer that way?
20180315 08:34:10< vultraz> I'm pondering if the HI needs that last recovery frame
20180315 08:36:37< vultraz> also, you're right, the lack of recovery seems a bit jarring
20180315 08:36:53< zookeeper> a lot of frames aren't "needed", but don't drop them if you don't have a specific reason.
20180315 08:37:35< zookeeper> or rather it's not the lack of recovery, it's the sudden shift between 13 and 14.
20180315 08:37:45< vultraz> yes
20180315 08:45:43< irker201> wesnoth: Charles Dang wesnoth:master c07063a85cbd / data/core/units/humans/Loyalist_Heavy_Infantryman.cfg: Further tweaks to Heavy Infantryman attack animation https://github.com/wesnoth/wesnoth/commit/c07063a85cbd0e64c918fd78a52ed8c07eeef703
20180315 08:45:56< vultraz> zookeeper: let me know if it needs more tweaking
20180315 08:52:19< vultraz> zookeeper: also, do you happen to know if the time it takes for units to move between hexes is hardcoded somewhere?
20180315 09:18:33< irker201> wesnoth: Sofartin wesnoth:master e8da52f4c4ae / projectfiles/Xcode/Wesnoth.xcodeproj/project.pbxproj: Fixed Xcode Project after dfc42e8 https://github.com/wesnoth/wesnoth/commit/e8da52f4c4ae95133c4d810fb687269d75c767ca
20180315 09:18:40< zookeeper> for movement? sure... not that i recall where.
20180315 09:25:07< zookeeper> probably easy to trace from the move_unit_between function, or maybe it's that 200.
20180315 09:29:27< vultraz> yeah, was also looking there
20180315 09:39:24-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20180315 09:40:06< zookeeper> ...any particular reason you wanted/needed to find out?
20180315 09:42:32< vultraz> I was considering that proposal i had back in 2016 to increase default animation/movement speed. Looking back, I realized the #1 thing I thought felt too slow at 1x speed was the movement time, not necessarily the animation time.
20180315 09:46:10-!- travis-ci [~travis-ci@ec2-54-234-144-117.compute-1.amazonaws.com] has joined #wesnoth-dev
20180315 09:46:11< travis-ci> wesnoth/wesnoth#16915 (master - e8da52f : Sofartin): The build was fixed.
20180315 09:46:11< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/353731698
20180315 09:46:11-!- travis-ci [~travis-ci@ec2-54-234-144-117.compute-1.amazonaws.com] has left #wesnoth-dev []
20180315 09:46:20< JyrkiVesterinen> \o/
20180315 09:46:23< vultraz> \o/
20180315 10:01:21-!- Bonobo [~Bonobo@203.63.93.247] has joined #wesnoth-dev
20180315 10:39:06-!- octalot [~steve@91.141.1.100.wireless.dyn.drei.com] has joined #wesnoth-dev
20180315 10:49:06-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20180315 10:51:10-!- JyrkiVesterinen [~JyrkiVest@195-192-251-124.s1networks.fi] has quit [Quit: .]
20180315 11:17:47-!- vladimirslavik [vslavik@nat/redhat/x-gllggeiigdnyrenb] has joined #wesnoth-dev
20180315 11:23:49-!- Appleman1234 [~quassel@124x38x163x22.ap124.ftth.ucom.ne.jp] has quit [Ping timeout: 260 seconds]
20180315 11:23:49-!- shadowm [~iris@wesnoth/developer/shadowm] has quit [Ping timeout: 260 seconds]
20180315 11:23:49-!- lobby [~wesnoth@wesnoth/bot/lobby] has quit [Ping timeout: 260 seconds]
20180315 11:25:00-!- lobby [~wesnoth@baldras.wesnoth.org] has joined #wesnoth-dev
20180315 11:25:00-!- Topic for #wesnoth-dev: String freeze in effect on master | 1.13.12 (1.14 RC 1) delayed until master branch stabilizes | Wesnoth Developers Channel | >>> Want to help? Go here: https://r.wesnoth.org/t42911 (and thanks!) <<< | Discord Server: https://discord.gg/battleforwesnoth | Logs: http://irclogs.wesnoth.org | Bug tracker: https://bugs.wesnoth.org
20180315 11:25:00-!- Topic set by JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] [Thu Mar  8 17:37:43 2018]
20180315 11:25:00[Users #wesnoth-dev]
20180315 11:25:00[ aeth           ] [ DDR            ] [ irker201    ] [ midzer    ] [ Ravana_    ] [ vincent_c     ] 
20180315 11:25:00[ AI0867         ] [ DeFender1031   ] [ Ivanovic    ] [ minzbonbon] [ Rhonda     ] [ vladimirslavik] 
20180315 11:25:00[ aidanhs        ] [ elias          ] [ janebot     ] [ new_one   ] [ Soliton    ] [ vn9711        ] 
20180315 11:25:00[ APic           ] [ EliDupree      ] [ Jetrel_bot  ] [ nore      ] [ stikonas   ] [ vultraz       ] 
20180315 11:25:00[ atarocch       ] [ esr            ] [ jrabe       ] [ nurupo    ] [ syrma[m]   ] [ wedge009      ] 
20180315 11:25:00[ Bonobo         ] [ galegosimpatico] [ lobby       ] [ octalot   ] [ TadCarlucci] [ yaiyan        ] 
20180315 11:25:00[ ChipmunkV[m]   ] [ Gambit         ] [ loonycyborg ] [ oldlaptop ] [ TheJJ_     ] [ zookeeper     ] 
20180315 11:25:00[ commavir       ] [ heirecka       ] [ madmax28    ] [ Polsaker  ] [ timotei_   ] 
20180315 11:25:00[ crimson_penguin] [ higgins        ] [ matthiaskrgr] [ pydsigner ] [ vihta      ] 
20180315 11:25:00-!- Irssi: #wesnoth-dev: Total of 52 nicks [0 ops, 0 halfops, 0 voices, 52 normal]
20180315 11:25:03-!- Channel #wesnoth-dev created Tue Jan 27 05:28:41 2009
20180315 11:27:19-!- Irssi: Join to #wesnoth-dev was synced in 147 secs
20180315 11:28:44-!- Appleman1234_ [~quassel@124x38x163x22.ap124.ftth.ucom.ne.jp] has joined #wesnoth-dev
20180315 11:28:44-!- aeth_ [~Michael@wesnoth/umc-dev/developer/aethaeryn] has joined #wesnoth-dev
20180315 11:28:45-!- ShikadiQueen [~iris@wesnoth/developer/shadowm] has joined #wesnoth-dev
20180315 11:28:45< irker201> wesnoth: Charles Dang wesnoth:master bba1dc264b85 / src/compile_time_tests/ieee_754.cpp: Made use of std::numeric_limits::is_iec559 https://github.com/wesnoth/wesnoth/commit/bba1dc264b85890824ac8d6ef8f4c82b98625068
20180315 11:28:45-!- crimson_pingvin [~crimson_p@ec2.happyspork.com] has joined #wesnoth-dev
20180315 11:28:47-!- Netsplit *.net <-> *.split quits: aeth
20180315 11:28:49-!- Netsplit *.net <-> *.split quits: crimson_penguin
20180315 11:28:49-!- crimson_pingvin is now known as crimson_penguin
20180315 11:28:49-!- crimson_penguin [~crimson_p@ec2.happyspork.com] has quit [Changing host]
20180315 11:28:49-!- crimson_penguin [~crimson_p@wesnoth/developer/crimsonpenguin] has joined #wesnoth-dev
20180315 11:29:00-!- Home page for #wesnoth-dev: https://www.wesnoth.org
20180315 11:38:33-!- JyrkiVesterinen [~JyrkiVest@195-192-251-124.s1networks.fi] has joined #wesnoth-dev
20180315 11:41:45-!- octalot [~steve@91.141.1.100.wireless.dyn.drei.com] has quit [Ping timeout: 264 seconds]
20180315 14:23:05-!- TC01 [~quassel@venus.arosser.com] has joined #wesnoth-dev
20180315 14:24:40-!- TC01 [~quassel@venus.arosser.com] has quit [Remote host closed the connection]
20180315 14:24:51-!- vultraz [uid24821@wesnoth/developer/vultraz] has quit [Quit: Connection closed for inactivity]
20180315 14:27:01-!- irker201 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20180315 15:06:56-!- irker134 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20180315 15:06:56< irker134> wesnoth/wesnoth:master Charles Dang bba1dc264b Made use of std::numeric_limits::is_iec5 AppVeyor: All builds passed
20180315 15:17:00-!- JyrkiVesterinen [~JyrkiVest@195-192-251-124.s1networks.fi] has quit [Quit: .]
20180315 15:20:40-!- TC01 [~quassel@venus.arosser.com] has joined #wesnoth-dev
20180315 15:33:06< irker134> wesnoth/wesnoth:master Sofartin e8da52f4c4 Fixed Xcode Project after dfc42e8 AppVeyor: All builds passed
20180315 16:14:08< vn9711> Guys, what is the fastest turn-around sequence for testing an add-on? 
20180315 16:14:08< vn9711> Currently, I have to 1. make changes in code 2. start wesnoth 3. click Multiplayer game 4. double-click Local game 5. click Next 6. click Ok 7. click I'm Ready.
20180315 16:14:46< vn9711> When I developed scenarios, it was just 1. make changes in code 2. start `wesnoth --multiplayer --scenario=your_id`
20180315 16:21:00-!- gfgtdf [~chatzilla@x4e363044.dyn.telefonica.de] has joined #wesnoth-dev
20180315 16:21:24< gfgtdf> what exactly are you changing?
20180315 16:22:20< gfgtdf> if your addosn code is in lua and use require/dofile you don't need to restart wesnoth or reload cace , just load the savefile.
20180315 16:29:21-!- JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] has joined #wesnoth-dev
20180315 16:31:12< vn9711> gfgtdf: hmm, interesting. But if I use a save file, I'll have a game already modified by preload events, which I wouldn't want in my particular case (at all).
20180315 16:31:21< Ravana_> for some changes you need to restart wesnoth, for some you need to delete cache files manually, for some f5 is enough, and some can be refreshed within scenario
20180315 16:31:56< gfgtdf> vn9711: you can probably use start-of-scenario saves ?also why aare you using preload events to change the gamestate?
20180315 16:32:03< vn9711> Ravana_: what does F5 do ?
20180315 16:32:51< Ravana_> reloads some config files, and I think marks some cache invalid
20180315 16:33:11< vn9711> gfgtdf: the save file will also contain changes at "start" and "prestart" events, so that doesn't really matter.
20180315 16:33:25< gfgtdf> vn9711: as i said, you can use start-of-scenario saves
20180315 16:34:08< vn9711> gfgtdf: what is a start-of-scenario save? Is it the same as a save made manually on first turn?
20180315 16:34:57< gfgtdf> vn9711: no it's that save that is made between two scenarios in a campaign and that does not have 'turn' in its name
20180315 16:35:22< vn9711> Ravana_: manually deleting cache is a nice trick. Could also be cool to have this built-in in wesnoth (like --nocache, but disables cache altogether).
20180315 16:35:58< Ravana_> not just trick, it is impossible to continue without deleting that
20180315 16:36:01< vn9711> gfgtdf: I don't know how to make one. Where can I read about it? I'm developing an add-on that could/should work on any map/era.
20180315 16:36:56< vn9711> Ravana_: well I was re-starting wesnoth, it made the cache become outdated too. Clearing it will make 1-2 steps less to re-create a new game.
20180315 16:37:18< vn9711> gfgtdf: I mean I'm developing a "mod".
20180315 16:37:26< gfgtdf> vn9711: you can for example make a 'dummy' scenario that does nothing but advaning to your scneario (put persistent=no in all sides of that scenario) the game will then create a start-of-scenario save
20180315 16:38:00< gfgtdf> vn9711: alterntively you can create one menually
20180315 16:38:09< vn9711> gfgtdf: that's hellish. I may try that..)
20180315 16:38:18< gfgtdf> vn9711: are you developing for 1.13 ?
20180315 16:39:14< gfgtdf> vn9711: start-of-scenario saves might be broken in mp on 1.12, so no luck there
20180315 16:43:06-!- vultraz [uid24821@wesnoth/developer/vultraz] has joined #wesnoth-dev
20180315 16:44:30< irker134> wesnoth/wesnoth:master Alexander van Gessel c0cab64c91 Use common crypt64::encode in server AppVeyor: vs2013/Release Failed
20180315 16:44:31< irker134> Details: https://ci.appveyor.com/project/wesnoth/wesnoth/build/Wesnoth-VS2013-master-1917
20180315 16:55:32-!- vladimirslavik [vslavik@nat/redhat/x-gllggeiigdnyrenb] has quit [Quit: Leaving]
20180315 17:01:34< vn9711> gfgtdf: trying to be compatible with both releases for now (well, 1.14 wasn't even released yet).
20180315 17:01:59< gfgtdf> ok but since is just about testing it will work if you test on 1.13
20180315 17:10:15< gfgtdf> hmm i just tried with stat-of-scenario saves and it doesn't seem to generate the leaders, seems liek a bug
20180315 17:17:29< zookeeper> vn9711, so why can't you start `wesnoth --multiplayer --scenario=your_id` anymore?
20180315 17:21:02< TadCarlucci> Other than the bug that, if you do, and you Load Turn 1 the game crashes to the desktop?
20180315 17:21:53< gfgtdf> in 2p aftermat the trnasition near the balck in the center are very sharp, is it uspposed to be like that ?
20180315 17:22:18< gfgtdf> in particular the whirlpool in he top left part of the center
20180315 17:22:20< zookeeper> 2p... aethermaw?
20180315 17:22:56< gfgtdf> the one with the mage in th emiddle
20180315 17:23:29< gfgtdf> 'allschlund' in german
20180315 17:26:45< zookeeper> the sharp water<->off-map (not void) transitions aren't intentional, sure.
20180315 17:27:08< zookeeper> but the little problems like between 21,20 and 22,19 are very hard to fix,
20180315 17:27:10< zookeeper> .
20180315 17:29:06< gfgtdf> there is also soem half-wall between 22,19 and 22,18
20180315 17:30:09< vn9711> zookeeper: because it's a "mod", not a scenario. The underlying problem I expected to be discussed is actually the lack of --modifications=  key when starting wesnoth. Wouldn't be a problem if there'd be good alternatives, but I'm not sure I'm satisfied with the already mentioned..
20180315 17:31:30< Soliton> sometimes it helps to make explicit what you want to discuss. :-P
20180315 17:31:51< Soliton> i think a feature request for that makes sense.
20180315 17:32:02< gfgtdf> if you remvoe fog there are also trnasiation issues on other places of that map.
20180315 17:33:50< irker134> wesnoth: Jyrki Vesterinen wesnoth:master 75b50979b64c / src/ (6 files in 2 dirs): Fix #2657: inability to scroll diagonally with keyboard https://github.com/wesnoth/wesnoth/commit/75b50979b64cbcdb56cd09e560bff376ad63bcc6
20180315 17:35:14< zookeeper> gfgtdf, want to take a screenshot of between 22,19 and 22,18? i see nothing.
20180315 17:36:47< gfgtdf> zookeeper: https://imgur.com/a/nOAVN
20180315 17:39:17< zookeeper> gfgtdf, uh, i have no idea why it would look like that to you, it's entirely different for me.
20180315 17:39:48< gfgtdf> i tested on 1.13.11 release, maybe it's fixed in master ?
20180315 17:40:27< zookeeper> oh right, of course. i fixed that on 21.2
20180315 17:40:44< vn9711> Soliton: I was planning to come to that, but I'm tearing up between IRC and real-life.. Anyway, will do. I definitely need this personally...
20180315 17:40:48< zookeeper> i thought it was much longer ago
20180315 17:44:19< vultraz> zookeeper: are we going to merge the dunefolk stuff for 1.13.12?
20180315 17:44:40< zookeeper> i don't know, it's not exactly my thing.
20180315 17:46:57< zookeeper> ohhhh, duh, i had been wondering why doofus's nighttime villages don't work right, but it's kind of obvious after all; they have a default 25% probability...
20180315 17:48:30< vultraz> that seems reasonable?
20180315 17:49:16< zookeeper> doesn't make any sense. if you have two villages of the same kind next to each other and one is lit during night and the other one isn't, the thing it most looks like is a bug.
20180315 17:49:31< vultraz> should it be 100%?
20180315 17:52:58< zookeeper> yes, i'll fix it. along with a few other things...
20180315 17:53:28< irker134> wesnoth/wesnoth:master Alexander van Gessel c0cab64c91 Use common crypt64::encode in server AppVeyor: 3/6 builds failed
20180315 17:53:29< irker134> Details vs2013/Release: https://ci.appveyor.com/project/wesnoth/wesnoth/build/Wesnoth-VS2013-master-1917
20180315 17:53:30< irker134> Details vs2015/Release: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/build/Wesnoth-VS2015-master-1903
20180315 17:53:31< irker134> Details vs2017/Release: https://ci.appveyor.com/project/wesnoth/wesnoth-605wt/build/Wesnoth-VS2017-master-1607
20180315 18:07:40-!- travis-ci [~travis-ci@ec2-54-234-144-117.compute-1.amazonaws.com] has joined #wesnoth-dev
20180315 18:07:41< travis-ci> AI0867/wesnoth#77 (base64-refactor - 566d99b : Alexander van Gessel): The build has errored.
20180315 18:07:41< travis-ci> Build details : https://travis-ci.org/AI0867/wesnoth/builds/353916117
20180315 18:07:41-!- travis-ci [~travis-ci@ec2-54-234-144-117.compute-1.amazonaws.com] has left #wesnoth-dev []
20180315 18:07:43-!- Bonobo [~Bonobo@203.63.93.247] has quit [Ping timeout: 256 seconds]
20180315 18:23:01-!- Ravana_ [~Ravana@unaffiliated/ravana/x-2327071] has quit []
20180315 18:24:59-!- Oebele [~quassel@143.177.58.202] has joined #wesnoth-dev
20180315 18:34:51-!- JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] has quit [Quit: .]
20180315 18:35:48< irker134> wesnoth: ln-zookeeper wesnoth:master 624a407c9457 / data/core/ (terrain-graphics.cfg terrain-graphics/new-macros.cfg): Fixed issues with NEW:VILLAGE_TOD https://github.com/wesnoth/wesnoth/commit/624a407c945720589b02c4d23a767860729fa04a
20180315 18:38:09-!- Ravana_ [~Ravana@unaffiliated/ravana/x-2327071] has joined #wesnoth-dev
20180315 18:38:28-!- JyrkiVesterinen [~jyrki@85-23-197-3.bb.dnainternet.fi] has joined #wesnoth-dev
20180315 18:45:17-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20180315 18:48:14-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20180315 18:48:31-!- aeth_ [~Michael@wesnoth/umc-dev/developer/aethaeryn] has quit [Ping timeout: 256 seconds]
20180315 18:50:08-!- aeth [~Michael@wesnoth/umc-dev/developer/aethaeryn] has joined #wesnoth-dev
20180315 18:51:02< irker134> wesnoth: Jyrki Vesterinen wesnoth:master 866e0f2b08e2 / src/hotkey/command_executor.cpp: Fix build with -Werror=switch https://github.com/wesnoth/wesnoth/commit/866e0f2b08e20ed328f865febcf05e1dbf220e2b
20180315 19:20:44-!- JyrkiVesterinen [~jyrki@85-23-197-3.bb.dnainternet.fi] has quit [Quit: .]
20180315 19:25:29-!- octalot [~steve@91.141.3.130.wireless.dyn.drei.com] has joined #wesnoth-dev
20180315 19:31:58-!- travis-ci [~travis-ci@ec2-54-234-144-117.compute-1.amazonaws.com] has joined #wesnoth-dev
20180315 19:31:59< travis-ci> AI0867/wesnoth#78 (base64-refactor - e68cdac : Alexander van Gessel): The build is still failing.
20180315 19:31:59< travis-ci> Build details : https://travis-ci.org/AI0867/wesnoth/builds/353924002
20180315 19:31:59-!- travis-ci [~travis-ci@ec2-54-234-144-117.compute-1.amazonaws.com] has left #wesnoth-dev []
20180315 19:57:19< vultraz> alright, I've decided RC 1 is going to be on Sunday.
20180315 19:57:57-!- vultraz changed the topic of #wesnoth-dev to: String freeze in effect on master | 1.13.12 (1.14 RC 1) scheduled for Sunday, March 18th, 00:01 UTC | Wesnoth Developers Channel | >>> Want to help? Go here: https://r.wesnoth.org/t42911 (and thanks!) <<< | Discord Server: https://discord.gg/battleforwesnoth | Logs: http://irclogs.wesnoth.org | Bug tracker: https://bugs.wesnoth.org
20180315 19:58:10< vultraz> we can't keep putting it off
20180315 20:03:13< vultraz> gfgtdf: btw do you think we should disable those "debug command used during turn of" messages?
20180315 20:04:19< zookeeper> might want to give them a short duration at least
20180315 20:04:32< gfgtdf> well clearly we cannot disable them completely sicne they tell you when another player in a mp game is using those commands to change the gamestate
20180315 20:04:52< gfgtdf> what woudl be acceptable is disabling them for the person that invoked them.
20180315 20:05:16< vultraz> if you use multiple commands in rapid succession the messages overlay each other too
20180315 20:05:44< vultraz> gfgtdf: how would one do that
20180315 20:06:31< zookeeper> the duration is customizable, and IIRC whoever complained about the messages recently was primarily annoyed by the messages staying on for too long.
20180315 20:06:46< vultraz> it's a full second
20180315 20:06:51< vultraz> I think?
20180315 20:06:55< vultraz> that's what the code says
20180315 20:07:03< vultraz> but they migh saty longer
20180315 20:07:15< gfgtdf> zookeeper: they are long on propose to amek sure that other player in mp will see them, even if they are afk for a second
20180315 20:07:31< gfgtdf> if you know the side a get_side(side).is_local() wheck might do it. a !is_replay() check might be needed aswell
20180315 20:08:30< vultraz> oh, no, it's 1000 frames
20180315 20:08:32< vultraz> ?
20180315 20:08:53< vultraz> maybe the doc is wrong
20180315 20:09:10< irker134> wesnoth: Alexander van Gessel wesnoth:master c70df4f8a71d / src/ (filesystem_boost.cpp server/player_connection.hpp): Remove old SVN cookies https://github.com/wesnoth/wesnoth/commit/c70df4f8a71d755f4efbeb77657177e175293a92
20180315 20:09:54< gfgtdf> we shodul make rename filesytem_boost.cpp, gettext_boost.cpp to just filestem.cpp adn gettext.cpp now the the odl implementation are gone
20180315 20:10:22< gfgtdf> s/make/maybe
20180315 20:11:00< zookeeper> gfgtdf, if another player uses debug mode locally to change the gamestate then that would usually lead to OOS, so i guess those messages are for when they only use debug mode to for example turn off fog, or something else that wouldn't (usually) lead to OOS?
20180315 20:12:54< gfgtdf> zookeeper: since 1.13 those debug commands are synced
20180315 20:13:22< zookeeper> uh, okay. how does that work? only the host can use debug commands?
20180315 20:14:18< gfgtdf> zookeeper: only the currently active player can do debug commands, just like for all other synced actions.i actualyl don'T know what happens when other player attempt to do it
20180315 20:15:33< Ravana_> it is not possible to use debug commands in mp, even in 1.13
20180315 20:16:28< gfgtdf> Ravana_: you can start wesnoth with -d commanline switch
20180315 20:29:12-!- gfgtdf [~chatzilla@x4e363044.dyn.telefonica.de] has quit [Read error: Connection reset by peer]
20180315 20:55:30< irker134> wesnoth: Charles Dang wesnoth:master c723ca4a4806 / src/synced_commands.cpp: Tweaked wording, and shortened duration, of debug command notifications https://github.com/wesnoth/wesnoth/commit/c723ca4a4806ab4b9ca9e749f83d60a15045f4aa
20180315 20:59:13-!- travis-ci [~travis-ci@ec2-54-234-144-117.compute-1.amazonaws.com] has joined #wesnoth-dev
20180315 20:59:14< travis-ci> wesnoth/wesnoth#16922 (master - c70df4f : Alexander van Gessel): The build passed.
20180315 20:59:14< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/354019094
20180315 20:59:14-!- travis-ci [~travis-ci@ec2-54-234-144-117.compute-1.amazonaws.com] has left #wesnoth-dev []
20180315 21:00:21< Ravana_> I see
20180315 21:00:37< Ravana_> btw, it doesn't report change side command with print
20180315 21:07:43< Soliton> so does that mean now i have to constantly watch the game to make sure i don't miss some other player cheating with debug commands?
20180315 21:09:05-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20180315 21:09:29< vultraz> ............
20180315 21:09:36< vultraz> sure?
20180315 21:11:30< Soliton> i'm afraid i have to point out that that is ridiculous.
20180315 21:15:35< APic> *shrug*
20180315 21:29:40< Soliton> ah, it gets better. the message that explains the cheating is not translatable so anyone not speaking english doesn't have a clue even if they happen to see the message.
20180315 21:41:32< vultraz> what would you have us do
20180315 21:41:44< vultraz> as gfgtdf said the commands probably cause oos anyway
20180315 21:43:13< Soliton> well then first advice would be to re-read what gfgtdf said.
20180315 21:43:56< Soliton> then perhaps decide if you want people to play multiplayer in 1.14 in any serious fashion.
20180315 21:43:58< vultraz> he said you could use -d
20180315 21:44:28< Soliton> if not then keep on going, nothing to worry about.
20180315 21:45:13< vultraz> why not offer some suggestions
20180315 21:46:05-!- gfgtdf [~chatzilla@x4e363044.dyn.telefonica.de] has joined #wesnoth-dev
20180315 21:46:26< vultraz> how do we sufficiently disable debug mode commands in mp without making it so people can never develop or debug mp content (already a PITA)
20180315 21:48:44< Soliton> so that's what that is for? a feature requested by mp add-on developers?
20180315 21:49:08< vultraz> what?
20180315 21:49:13< vultraz> is "this"
20180315 21:49:43< gfgtdf> well it does not really matter whether it stays 250 ro 1000 of whatever time unit. Neither will suffice if the people to other thigns like going to the toilet, what we need is soemthing that guranetees that the text will be seen which requires probably something more complicated like '250 after the last user input' or a dialog that needs to clicked away.
20180315 21:49:52< gfgtdf> s/ro/or
20180315 21:50:45< Soliton> a dialog like the oos dialog in 1.12? not all hope is lost yet, i suppose.
20180315 21:51:02< Soliton> it's really hard to stay serious.
20180315 21:51:22< Soliton> but i guess 1.14 mp is a train wreck waiting to happen anyway.
20180315 21:51:43< vultraz> Your support is so encouraging
20180315 21:52:31< Ravana_> my opinion is mp debug mode is just not needed, modification can implement most of those commands - I think only foreground, layers, manage, sunset, unsafe_lua can not be used without debug
20180315 21:52:44< vultraz> sunset was removed
20180315 21:52:59< vultraz> the hell does foreground do
20180315 21:53:01< Ravana_> possible, used 1.12 :help for list
20180315 21:53:54< ShikadiQueen> Okay what is this...
20180315 21:54:19< ShikadiQueen> I remember complaining back in 1.11.x because someone decided it'd be a great idea to let people use :debug in multiplayer. Naturally my complaints were shot down.
20180315 21:54:42< ShikadiQueen> And about 4 years later we're revisiting the issue?
20180315 21:55:50< Soliton> the difference is that debug commands are now synced so there's no oos. so if you want to cheat that way it actually just works.
20180315 21:56:02< vultraz> debug mode cannot be activated in mp
20180315 21:56:10< vultraz> but nothing stops you from having it already activated
20180315 21:56:31< loonycyborg> maybe server should check for this?
20180315 21:56:42< loonycyborg> because can't rely on client for this
20180315 21:56:49< loonycyborg> since you can just modify it
20180315 21:56:53< Soliton> i doubt that'd be easy/possible.
20180315 21:56:56< ShikadiQueen> I have a feeling the server won't be able to tell apart debug commands from WML events in that case.
20180315 21:57:17< Soliton> not sure how the WML looks for theses commands though. maybe it is.
20180315 21:57:48< loonycyborg> anyway ability to modify client lets you to see potentially everything that your client has knowledge of
20180315 21:58:08< Soliton> sure, that's something we can't easily change.
20180315 21:58:38< Soliton> doesn't mean we have to build in features for it to give itself more gold etc.
20180315 21:58:47< Ravana_> just modifying some core Lua files is enough to provide you undetectable access to :inspect at any time
20180315 21:58:59< gfgtdf> the server could easily block these new synced debug commands
20180315 21:59:19< Soliton> ok. that's something at least.
20180315 21:59:54< gfgtdf> (which of course doesnt mean it can completeley prevent cheating)
20180315 22:00:13< gfgtdf> in particular since [do_command][lua_ai] exists.
20180315 22:00:15< Ravana_> debug mode could be setting when creating mp game, if visible enough then it would limit its use to just developing
20180315 22:00:34< gfgtdf> which does not even need debug mode.
20180315 22:01:01< ShikadiQueen> Ravana_: Not really.
20180315 22:01:22< Soliton> gfgtdf: what can you do with that?
20180315 22:02:09< ShikadiQueen> Even if you make it plainly visible on the game list, unless it clearly says "CHEATING IS ENABLED BY ONE OR MORE PLAYERS" people won't understand the implications.
20180315 22:02:15< ShikadiQueen> And yes, it'd have to say "cheating".
20180315 22:02:45< ShikadiQueen> The average newbie can't be expected to understand what debug mode entails.
20180315 22:03:12< gfgtdf> same as :lua but without any user visible message, it's basicilly the cheat backdoor for ai code.
20180315 22:04:19< Soliton> great.
20180315 22:06:01< Soliton> and that is synced as well? or do you need to write some lua in your scenario to make use of it?
20180315 22:06:34< vultraz> This is what happens when MP relies on the host sending everything, instead of a server running the gamestate and dispatching the result to all clients, host included.
20180315 22:07:29< Soliton> the host just sends the initial scenario which you can see is a known scenario in the lobby.
20180315 22:07:38< Soliton> well could in 1.12 probably gone now.
20180315 22:08:08< vultraz> whether or not a scenario is known or not is less in-your-face
20180315 22:08:14< vultraz> no more "Unknown Scenario"
20180315 22:08:19< gfgtdf> Soliton: it's synced, you can use it as non-host. it also exists in 1.12
20180315 22:08:48< gfgtdf> Soliton: (although a little harder to use in 1.12)
20180315 22:09:22< Soliton> sad.
20180315 22:09:39< Soliton> you used to have a chance to detect cheating.
20180315 22:10:23< zookeeper> btw, do other similar messages (such as [print]) override the previous message, or are they just drawn on top of each other?
20180315 22:10:52< zookeeper> because if you can trigger a legitimate message in the scenario, you can just cheat right before that and have the debug command message disappear or maybe at least be indecipherable.
20180315 22:11:24< ShikadiQueen> Why not use a dialog like it was suggested above?
20180315 22:12:24< zookeeper> or just print the messages into the chat/whatever queue instead. basically all other debug/error/warning/etc messages go there anyway...
20180315 22:13:53< Soliton> gfgtdf: just so i clearly understand it. you can make your client only send [do_command][lua_ai] to do whatever you want and the other clients will faithfully execute that, yes? why is it harder to use in 1.12?
20180315 22:14:09 * zookeeper was just about to ask the same
20180315 22:15:07< Soliton> (what do we use that feature for? the ai i guess but what specifically...)
20180315 22:16:05< gfgtdf> yes, it's harder to use in 1.12 becasue 1.12 does not have [do_command], it has the same function as "ai.synced_command" but you need to do some work to get access to it, i actuall dont' know the details since i don't know much about ai coding
20180315 22:16:35< gfgtdf> Soliton: there is also a bugreport about it https://github.com/wesnoth/wesnoth/issues/1649
20180315 22:16:48< gfgtdf> Soliton: https://github.com/wesnoth/wesnoth/search?l=Lua&q=synced_command&type=&utf8=%E2%9C%93
20180315 22:17:30< Soliton> thanks.
20180315 22:20:06 * Soliton would make that a blocker bug but...
20180315 22:21:29< Soliton> hmmm, could check all replays to see if this was ever used for something shady...
20180315 22:22:13< APic> Hmm.
20180315 22:24:28< gfgtdf> you have to search for '[lua_ai]' then
20180315 22:25:13< Soliton> why is this used in sotbe, btw? that's sp surely.
20180315 22:26:52< gfgtdf> for replays, mp-sync = replay-sync
20180315 22:27:57< Soliton> if those 3 places are all the mainline uses it seems like it shouldn't be that hard to just remove this feature and find something much more restrictive.
20180315 22:29:24< mattsc> Soliton: the original use in SotBE was to enable the AI to do something that was not possible with the other ai.*() commands without causing OOSs.
20180315 22:29:40< mattsc> Specifically, that meant putting units on the map (unloading them from ships).
20180315 22:30:20< Soliton> why does the ai have to do that? why can't some scenario wml/lua do it?
20180315 22:30:45-!- Oebele [~quassel@143.177.58.202] has quit [Remote host closed the connection]
20180315 22:32:22< mattsc> It could, but it’s really inconvenient to write any sort of adaptable AI behavior in WML.
20180315 22:33:53< gfgtdf> i still think the best way is to just allow registering synced command that can then be used, i just don't know how to do that from within the ai code.
20180315 22:33:55< mattsc> And at the time, I had no idea about any sort of security issues.  And nobody else said anything either until gfgtdf brought it up many years later.
20180315 22:34:03< Soliton> i suppose i understand that but giving the ai (and by extension anyone) a generic way to do whatever it wants cannot be the solution to that.
20180315 22:34:26< mattsc> Soliton: not arguing that, just explaining what happened.
20180315 22:34:37< Soliton> sure, i appreciate that.
20180315 22:35:01< Soliton> if you can explain what those micro ais use it for i'd be interested.
20180315 22:35:13< mattsc> Uh, let me have a look.
20180315 22:35:43< gfgtdf> so for scenario-specific ais we could just force people to put the corresponding 'register function's in the scenariowml code which is rather easy.
20180315 22:36:01< Soliton> gfgtdf: yes, that'd already be a lot better.
20180315 22:36:15< mattsc> Oh, same thing.  Putting units on the map or taking them off.  (The specific use case example is having rabbits disappear into their holes, or coming back out of them.
20180315 22:36:31< Soliton> if you then can tell if a scenario is unmodified you can be certain of no cheating again.
20180315 22:36:55< Soliton> mattsc: i see, thanks.
20180315 22:36:56< gfgtdf> next question woudl be whether ai.synced_command is ever used in a ai that is suposed to work in any scenario. < mattsc?
20180315 22:37:19< Soliton> that micro ai presumably.
20180315 22:37:46< Soliton> but you have to put stuff for them into the scenario anyway, right?
20180315 22:37:47< mattsc> Right, the Micro AI should be generally usable.
20180315 22:37:55< mattsc> That’s right.
20180315 22:38:06< Soliton> that should be fine then.
20180315 22:38:20< gfgtdf> are those micro ais used in mainline ?
20180315 22:38:50< mattsc> Only in the test scenarios, I think.
20180315 22:38:51< zookeeper> i'd like to point out that the SotBE stuff _was_ written in WML originally and it worked just fine.
20180315 22:39:42< mattsc> zookeeper: it worked, but it had some issues with what it did; the new AI behavior is, IMO, significantly better.
20180315 22:40:16< mattsc> E.g. where the boats land etc.
20180315 22:40:22< zookeeper> oh? well, i don't remember the details of why you wanted to do it with lua.
20180315 22:41:02< Soliton> presumably it's more dynamic now. you don't know exactly where the ships will land?
20180315 22:41:11< mattsc> There was something about it being possible to keep the boats from landing and unloading at all if you placed your own units in the right place.
20180315 22:41:22< mattsc> Which made the scenario _way_ easier than it was supposed to be.
20180315 22:41:42< mattsc> That might not be exactly what happened, but it was something along those lines.
20180315 22:41:47< zookeeper> nah, the WML method already randomized the locations but maybe there was some other issue like those.
20180315 22:42:24< Soliton> ok. well the main point i guess is that it wouldn't be that big a deal to have to revert to the WML method.
20180315 22:43:12< Soliton> and the rabbit micro ai does not strike me as that essential either...
20180315 22:44:45< mattsc> The rabbit AI is just a little gimmick(?) because the capability existed.  I do know that it is used in UMC though.
20180315 22:44:57< zookeeper> looking at it now, it looks like it's really only the movement part that the lua AI implements. the move destinations are still set from WML, and the AI basically only acts as a more intelligent goto handler... except that the unit unloading code is bundled in there.
20180315 22:45:46< Soliton> it decides where to unload though?
20180315 22:45:58< Soliton> but the unloading could be done in WML, i guess.
20180315 22:46:21< zookeeper> yes
20180315 22:46:37< Soliton> the ai would just need to trigger an event or whatever.
20180315 22:46:51< Soliton> that sounds a lot saner to me.
20180315 22:48:15< zookeeper> sure, that use of synced_command could be avoided. not that i'd want to be the one to untangle it...
20180315 22:48:45< mattsc> How do you “make the AI trigger an event”?
20180315 22:49:05< Soliton> that is an excellent question. :-)
20180315 22:49:11< zookeeper> unless i'm missing something, you don't even need to, you could just use a moveto event?
20180315 22:49:14< mattsc> I can see how you can make the AI move a unit, and if the move satisfies some conditions, that would trigger an event.
20180315 22:49:37< mattsc> Which could be made to work in SotBE S6, I guess.
20180315 22:49:44< zookeeper> in this case i believe the unloading happens whenever a boat moves adjacent to non-water
20180315 22:49:55< mattsc> Not so easy with the rabbits appearing out of the holes (having them disappear is easier).
20180315 22:50:26< mattsc> zookeeper: right, that’s what I meant.
20180315 22:50:40< Soliton> make special terrain for the rabbit holes?
20180315 22:50:42< mattsc> You’d just have to make sure the AI does not move next to non-water before it is ready to unload.
20180315 22:51:04< Soliton> (and trigger on moving on that terrain.)
20180315 22:51:06< mattsc> Soliton: the terrain is marked by items/images, so that could be checked.
20180315 22:51:30< mattsc> But the appearance is semi-random, but only if some other conditions are also met (no enemies close, etc.)
20180315 22:51:39< mattsc> So that logic would also have to be moved out of the AI.
20180315 22:52:47< mattsc> Anywas, to answer zookeeper’s question from a bit ago: I did it in the Lua AI code because that was easier and more flexible, and because I was not aware of a reason not to.
20180315 22:53:10< gfgtdf> i'm soon going to remove sycned_command and add custom_command, i don't knwo how to register cppaiapifunction so i'll not add one, but [do_command] can of course also be used in mp.
20180315 22:55:25< mattsc> Btw, I have another use of ai.synced_command in one of my UMC campaigns, but it’s again for putting units on the map.
20180315 22:56:05< mattsc> I’m not sure if there’s any other uses in other UMC.  There aren’t a lot of people who play around with AI code.
20180315 22:56:34< Soliton> it'd make sense to add features to allow the ai to fire events directly or set scenario variables or whatever to allow easier interaction with the scenario.
20180315 22:58:05< mattsc> That would be nice.
20180315 23:05:06< gfgtdf> mattsc: ca_forest_animals_new_rabbit.lua and ca_forest_animals_move.lua are alwys used together ?
20180315 23:06:28< mattsc> gfgtdf: They are in the MAI, yes, but in principle there is no reason why that needs to be done.
20180315 23:07:11< gfgtdf> but it looks liek one adds units and the other one remove sthem
20180315 23:08:59< mattsc> Hmm, yeah, looks like if you want to control “rabbits” (rabbit-like behavior; could be villagers appearing from and disappearing in huts, for example), you need both.
20180315 23:09:21< mattsc> But ca_forest_animals_move.lua could be run without the rabbits.
20180315 23:09:55< gfgtdf> mattsc: is there a reason why ca_transport_S6.lua does it's action in 3 different synced_command instado of doing all in one ?
20180315 23:12:00< mattsc> Probably not.  Don’t remember, but it looks like it could all be done in one.
20180315 23:13:17< mattsc> Btw, just looking at the code again, the event to unload could be triggered simply by the ship moving next to land.
20180315 23:13:42< mattsc> But the AI code also does an evaluation of which hexes to unload the three units onto.
20180315 23:14:10< mattsc> And that would be much harder to do in WML.  Not impossible, obviously, just more cumbersome.
20180315 23:14:48< Soliton> for that it'd be useful to be able to set a WML variable from the ai that you could use in the event.
20180315 23:15:21< mattsc> Absolutely.  And if I had had that available at the time, that’s how I would have done it.
20180315 23:15:24< Soliton> that seems fairly generically useful. not that i have nay clue how difficult that'd be to implement...
20180315 23:16:10< Soliton> perhaps celmin has some insight on that...
20180315 23:17:23< gfgtdf> we already have [do_command][fire_event] (which is how menu items are implemented)
20180315 23:18:42< mattsc> That didn’t exist 5 years ago though, right?
20180315 23:18:55< mattsc> And can you pas information via that?
20180315 23:20:30< mattsc> I’ve never used it before and don’t know how to use it from an AI environment...
20180315 23:21:04< gfgtdf> [do_command] is new in 1.13
20180315 23:21:21< gfgtdf> it can basicially invoke all type of commands attack/move/ etc.
20180315 23:21:23< mattsc> Yeah, I just checked the wiki
20180315 23:21:32< gfgtdf> accepts replaywml
20180315 23:22:00< mattsc> attacks/moves/etc. I can already do from the AI
20180315 23:22:18< mattsc> The main question I still have is whether I can pass information to a WML event
20180315 23:23:32< mattsc> Say, I have a custom event name=create_unit, can I pass the unit type and the hex where to create the unit from inside the Lua AI?
20180315 23:23:41< gfgtdf> i currently intend to add a [custom_command] synced action that calls a lua function, similar to events, but passes the 
20180315 23:27:54< mattsc> Anyways, I have to take off for a medical appointment.  I have no personal opinion on how any of this should be implemented (and security/cheating holes should be fixed, of course), but it would be nice to retain the functionality.
20180315 23:28:20< mattsc> I’ll check back in again later, I won’t be able to do much for the next two weeks though, traveling again ...
20180315 23:29:41-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.]
20180315 23:38:43-!- travis-ci [~travis-ci@ec2-54-161-229-116.compute-1.amazonaws.com] has joined #wesnoth-dev
20180315 23:38:44< travis-ci> AI0867/wesnoth#79 (base64-refactor - d450735 : Alexander van Gessel): The build is still failing.
20180315 23:38:44< travis-ci> Build details : https://travis-ci.org/AI0867/wesnoth/builds/354093505
20180315 23:38:44-!- travis-ci [~travis-ci@ec2-54-161-229-116.compute-1.amazonaws.com] has left #wesnoth-dev []
20180315 23:40:51< gfgtdf> mattsc: opened #2663 it clearly need to be polished a bit, and it's completely untested though.
20180315 23:41:00< vultraz> gfgtdf: we don't need to use helper.set_wml_tag_metatable {} anymore, just use `local T = wml.tag`
20180315 23:42:02< gfgtdf> most importantly those cusotom actiosn need to be givne good names and thos emacros need to be moved out of main.cfg
20180315 23:43:11< gfgtdf> vul ye i probably don't even need those these.
20180315 23:49:47-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20180315 23:50:33< vultraz> celticminstrel: did you say at some point we should remove wml.variable.set/get?
20180315 23:52:18< gfgtdf> the reason for that was probably that we have variable["name"] = value
20180315 23:52:37< gfgtdf> variables["name"]
20180315 23:52:39< vultraz> yes
20180315 23:53:24< vultraz> btw does variables.name also work?
20180315 23:53:28< Soliton> celticminstrel: if you want to make default+dunefolk default i suggest getting some expert players together to try to balance that new default as well as current default is. if that can even be done then it'd be fine to make it the new default era.
20180315 23:53:32< vultraz> since I noticed that with the wml tag metatable
20180315 23:53:33< vultraz> wml.tag
20180315 23:53:38< vultraz> you can do wml.tag.foo
20180315 23:53:43< vultraz> and wml.tag["foo"]
20180315 23:53:57< gfgtdf> yes it does
20180315 23:53:59< vultraz> so doe wml.variables.foo and wml.variables["foo"] both work?
20180315 23:54:00< vultraz> do
20180315 23:54:11< gfgtdf> but only for toplevel varaibles
20180315 23:54:24< vultraz> which is preferred?
20180315 23:54:32< gfgtdf> so wml.variables.foo[9].bar might not work
20180315 23:54:49< gfgtdf> there you might need to write wml.variables["foo[9].bar "]
20180315 23:54:54< vultraz> I see
20180315 23:55:00< celticminstrel> vultraz: variables.name is the same as variables["name"], but variables.name.subkey is not the same as variables["name.subkey"].
20180315 23:55:04< gfgtdf> for simple things i'd prefer wml.variables.foo
20180315 23:55:30< celticminstrel> variables.name.subkey will just give an error.
20180315 23:55:37< vultraz> im converting mainline uses of wesnoth.set_variable and was just wondering which i should use
20180315 23:55:38< celticminstrel> I too would prefer dots whenever possible.
20180315 23:55:41< vultraz> ok
20180315 23:55:42< vultraz> dots it is
20180315 23:55:56< celticminstrel> This is a generic property of Lua BTW.
20180315 23:56:04< celticminstrel> x.y is always equivalent to x["y"].
20180315 23:56:28< vultraz> but something like this needs [] right
20180315 23:56:29< vultraz> V[string.format("bandit_villages[%d]"] = i - 1
20180315 23:56:33< celticminstrel> Soliton: I don't even know any such players, so...
20180315 23:56:41< celticminstrel> vultraz: Uh not quite.
20180315 23:56:47< celticminstrel> Or wait. No, you're right.
20180315 23:57:24< Soliton> celticminstrel: sure. just mentioning how it should be done.
20180315 23:57:24< celticminstrel> I think we should rename wml.vars to something that won't cause people to confuse it with wml.variables.
20180315 23:57:28< celticminstrel> Any suggestions?
20180315 23:57:39< gfgtdf> what does vars do ?
20180315 23:57:48< celticminstrel> gfgtdf: It's a module.
20180315 23:58:10< celticminstrel> This needs pofix: https://github.com/wesnoth/wesnoth/commit/c723ca4a4806ab4b9ca9e749f83d60a15045f4aa
20180315 23:58:18< vultraz> which would you guys prefer as a local alias for wml.variables
20180315 23:58:23< vultraz> V or vars
20180315 23:58:24< celticminstrel> Can someone who understands pofix better than vultraz please do it?
20180315 23:58:35< vultraz> celticminstrel: no it doesn't
20180315 23:58:36< celticminstrel> vultraz: Well the latter would enhance the confusion I just mentioned.
20180315 23:58:40< vultraz> those are not translatable
20180315 23:58:43< celticminstrel> vultraz: Says who?
20180315 23:58:51< celticminstrel> ...oh wait, not translatable?
20180315 23:58:52< vultraz> there's no _
20180315 23:59:05< celticminstrel> Probably should be, but okay, if there isn't, I guess it's fine.
20180315 23:59:20< vultraz> unless vgettext makes things translatable
20180315 23:59:35< celticminstrel> It doesn't magically make things translatable, no.
20180315 23:59:48< celticminstrel> If you pass it a string that's not already translatable, it won't make it translatable.
20180315 23:59:55< gfgtdf> yes there shoudl be, but we are in a strign freeze
--- Log closed Fri Mar 16 00:00:06 2018