--- Log opened Mon Mar 18 00:00:29 2019 20190318 01:40:28-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 252 seconds] 20190318 02:03:14< irker019> wesnoth/wesnoth:master gfgtdf c6a7425c6a add [modify_unit][set_variable] AppVeyor: All builds passed 20190318 02:30:49<+wesdiscordbot> Hi! I wanted to ask about wesnoth and AI. What do you think of the game's potential as a platform for AI research in game playing? (Lately SC2 is quite popular in this regard) 20190318 02:33:44<+wesdiscordbot> seems interesting 20190318 02:35:03<+wesdiscordbot> though it doesn't use a true RNG for combat simulation, it's still close enough to not be deterministic for long stretches of values 20190318 02:35:26<+wesdiscordbot> so I wonder how the computer would handle risk management, which doesn't exist in something like chess or go or other similar board games 20190318 02:36:46<+wesdiscordbot> the ruleset is relatively more complicated as well 20190318 03:29:40<+wesdiscordbot> it would be interesting to see how well the AI can handle non-deterministic outcomes, and that how fast it can make moves provides no real benefit 20190318 03:29:59<+wesdiscordbot> especially compared to games like SC2 where micromanagement is a huge deal 20190318 03:31:01<+wesdiscordbot> I'm thinking of this article, for example: https://arstechnica.com/gaming/2019/01/an-ai-crushed-two-human-pros-at-starcraft-but-it-wasnt-a-fair-fight/ 20190318 03:34:27<+wesdiscordbot> @bruh rabbit ^ 20190318 03:36:07<+wesdiscordbot> right, how fast you play isn't an issue in wesnoth unless you have the timer on 20190318 03:42:48<+wesdiscordbot> assuming someone figured out how to make it interact with wesnoth though, it'd definitely be neat to see what happened after an AI like in that article trained itself through however many thousands of games. 20190318 03:48:02<+wesdiscordbot> xD 20190318 03:48:17<+wesdiscordbot> I wonder what would happen if it used Ageless Era 20190318 03:48:28<+wesdiscordbot> :thonk: 20190318 03:49:35<+wesdiscordbot> In this article the authors apparently removed SC2's macro management by introducing a partial obervability condition https://arxiv.org/abs/1705.08926 20190318 03:50:45<+wesdiscordbot> In a way wesnoth has already mechanisms for controlling observability (full or partial) and the stochasticity seems like what is looked for in research communities 20190318 03:54:25<+wesdiscordbot> yes, it's possible to make the ai play under the same conditions as a human 20190318 03:55:12<+wesdiscordbot> it's true that wesnoth has an algorithm for an RNG, but I wonder if the computer can abuse the fact that it's still not a true RNG 20190318 03:55:43<+wesdiscordbot> What's RNG? 20190318 03:55:49<+wesdiscordbot> random number genreator 20190318 03:55:51<+wesdiscordbot> generator 20190318 03:57:19<+wesdiscordbot> Well that would be interesting to see, provided that it can learn to play at a decent human level first 20190318 03:57:34<+wesdiscordbot> So I wouldn't worry about it 20190318 04:00:34<+wesdiscordbot> Still when I see researchers adding features to games to challenge their AIs further or to guide their training, I often notice that those features are originally present in wesnoth (like the example of macro-actions, and some actions becoming invalid when partial observability is introduced) 20190318 04:01:04<+wesdiscordbot> one thing to consider is that some players already have trouble against the ai 20190318 04:01:49<+wesdiscordbot> it does do some things that are incredibly stupid, but it doesplay with some amount of strategy 20190318 04:02:06<+wesdiscordbot> Me being one of them. But I'm by no means what one qualifies as a good player. Do you know what kind of heuristics are used in the current ai? 20190318 04:02:41<+wesdiscordbot> @mattsc ^ 20190318 04:03:01<+wesdiscordbot> mattsc is the one who deals with ai, so he can tell you more 20190318 04:04:23<+wesdiscordbot> Also sometimes the difficulty level is increased by increasing the number of units. Even with ordinary heuristics, the ai is sure to give a fight with an army of wraiths 20190318 04:05:37<+wesdiscordbot> well yes 20190318 04:06:01<+wesdiscordbot> but that's just brute force, not any amount of learning 20190318 04:06:39<+wesdiscordbot> it's really a matter of how much brute force is needed to overcome the better strategy 20190318 04:07:06<+wesdiscordbot> in some cases, turns out no matter how many units the ai gets, it'll never win 20190318 04:07:56<+wesdiscordbot> anyway time for me to attempt to 💤 20190318 04:08:14<+wesdiscordbot> 😱 20190318 04:08:26<+wesdiscordbot> That's an interesting point; an ai training on the edge of necessary brute force would be optimal 20190318 04:08:38<+wesdiscordbot> Okay good night ^^ thanks for the insights 20190318 04:20:25< celticminstrel> FTR you can probably learn quite a bit about the current Wesnoth AI by reading the wiki articles. 20190318 05:03:45-!- irker019 [~irker@wesnoth/umc-dev/bot/shikadibot] has quit [Quit: transmission timeout] 20190318 06:21:13-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev 20190318 06:51:43<+wesdiscordbot> Btw, how long is the string freeze this time? 20190318 07:01:35-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev 20190318 07:17:40<+wesdiscordbot> a month again 20190318 07:17:42<+wesdiscordbot> http://mailman.wesnoth.org/pipermail/i18n/2019-March/000033.html 20190318 07:36:23<+wesdiscordbot> Thanks. 20190318 08:41:35<+wesdiscordbot> Pentarctagon: I wonder what would happen if it used Ageless Era 20190318 08:41:51<+wesdiscordbot> Use Ageless Era with the experimental AI and see what happens 20190318 08:42:51<+wesdiscordbot> It's smart enought to not recruit Units which it considers not worthy it 20190318 09:32:34-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20190318 09:34:32-!- boucman_work [~boucman@wesnoth/developer/boucman] has quit [Ping timeout: 250 seconds] 20190318 09:49:31-!- boucman_work [~boucman@wesnoth/developer/boucman] has joined #wesnoth-dev 20190318 10:01:51-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 252 seconds] 20190318 10:35:34< Soliton> @bruh rabbit one of the design goals of wesnoth was actually to have simple rules that can be easily implemented in an AI. 20190318 11:34:09-!- boucman_work [~boucman@wesnoth/developer/boucman] has quit [Ping timeout: 250 seconds] 20190318 11:50:23-!- boucman_work [~boucman@wesnoth/developer/boucman] has joined #wesnoth-dev 20190318 12:06:57-!- wesdiscordbot1 [~wesdiscor@wesnoth/bot/discord-bridge] has joined #wesnoth-dev 20190318 12:06:59-!- mode/#wesnoth-dev [+v wesdiscordbot1] by ChanServ 20190318 12:10:27-!- wesdiscordbot [~wesdiscor@wesnoth/bot/discord-bridge] has quit [Ping timeout: 240 seconds] 20190318 12:10:53-!- wesdiscordbot1 is now known as wesdiscordbot 20190318 12:36:04-!- celticminstrel is now known as celmin|away 20190318 13:46:44-!- boucman_work [~boucman@wesnoth/developer/boucman] has quit [Ping timeout: 250 seconds] 20190318 13:59:27-!- boucman_work [~boucman@wesnoth/developer/boucman] has joined #wesnoth-dev 20190318 14:41:43-!- boucman_work [~boucman@wesnoth/developer/boucman] has quit [Ping timeout: 245 seconds] 20190318 14:54:38-!- boucman_work [~boucman@wesnoth/developer/boucman] has joined #wesnoth-dev 20190318 15:38:16-!- boucman_work [~boucman@wesnoth/developer/boucman] has quit [Ping timeout: 246 seconds] 20190318 15:50:35-!- boucman_work [~boucman@wesnoth/developer/boucman] has joined #wesnoth-dev 20190318 16:07:08-!- boucman_work [~boucman@wesnoth/developer/boucman] has quit [Ping timeout: 245 seconds] 20190318 16:27:49-!- boucman_work [~boucman@wesnoth/developer/boucman] has joined #wesnoth-dev 20190318 16:50:16-!- boucman_work [~boucman@wesnoth/developer/boucman] has quit [Ping timeout: 255 seconds] 20190318 16:50:34-!- boucman_work [~boucman@wesnoth/developer/boucman] has joined #wesnoth-dev 20190318 17:26:00-!- boucman_work [~boucman@wesnoth/developer/boucman] has quit [Ping timeout: 250 seconds] 20190318 17:54:53-!- gfgtdf [~Daniel@x5f745f02.dyn.telefonica.de] has joined #wesnoth-dev 20190318 17:59:18< gfgtdf> i think that codes like `cfg = std::move(cfg.child("somechild"))` would crash, i wonder whether it is possibel to invoke such a call in wml/lua, which would give use a reason to 'fix' this. 20190318 18:03:25<+wesdiscordbot> You can remove std::move(). The example expression you gave already returns an rvalue. 20190318 18:43:31< gfgtdf> @jyrkive im quite sure config::child retun just a config& 20190318 18:44:03<+wesdiscordbot> Yes, but it becomes an rvalue if you don't bind it to a named variable. 20190318 18:46:02< gfgtdf> no it doesnt, where did you read it does that? 20190318 18:47:35<+wesdiscordbot> It's explained in the very first page of this article: http://thbecker.net/articles/rvalue_references/section_01.html 20190318 18:47:58<+wesdiscordbot> cpp j = foobar(); // ok, foobar() is an rvalue 20190318 18:49:00< gfgtdf> thast foobar returned by value and not by reference. 20190318 18:49:29< gfgtdf> child returns `config&` and not `config` 20190318 18:50:06<+wesdiscordbot> Oh. You're right. 20190318 18:50:26<+wesdiscordbot> I always forget that function return value is an lvalue if it's a reference type. 😦 20190318 19:04:34<+wesdiscordbot> gfgtdf did you see what I posted last night? 20190318 19:05:11< gfgtdf> @Iris no, here on the channel? 20190318 19:05:19<+wesdiscordbot> yes 20190318 19:05:53< gfgtdf> let me look 20190318 19:13:32< gfgtdf> from looking at the code wesnoth.map.get_direction shodul support the - syntax iff terrainfilter do 20190318 19:18:24< gfgtdf> @Iris also your code might not have worked in 1.12 when people disabled animations since there was a bug when facing was not set when animations/fights were disabled. (This was once a knwon OOS casue in ageless iirc) 20190318 19:19:03<+wesdiscordbot> Well, I advised people to enable animations just in case since the campaign is heavily reliant on them 20190318 19:22:15<+wesdiscordbot> https://cdn.discordapp.com/attachments/259976436490829825/557282633654992896/unknown.png 20190318 19:22:23<+wesdiscordbot> so that works 20190318 19:24:47<+wesdiscordbot> what else could possibly go wrong then? 20190318 19:25:57< gfgtdf> hmm not sure, just tested 'wesnoth.get_locations({ wml.tag.filter_adjacent_location { x=9, y = 9, adjacent="-n"}})' it also worked 20190318 19:27:20<+wesdiscordbot> "name: filter on the attack's name. See data/units/ or http://www.wesnoth.org/units/ to find the name of a particular unit's attack." ← does whoever wrote this in the standard weapon filter documentation realize that names displayed on the units database are the display names and not the internal names? 20190318 19:30:52< gfgtdf> you coudl just the wiki heastory feature, to find out who and then ask the person if you really want to know. 20190318 19:31:13<+wesdiscordbot> That was a rhetorical question 20190318 19:34:04<+wesdiscordbot> It's been so long that perhaps I did misunderstand the WML logic and it relies on something that changed in 1.13.x 20190318 19:34:57<+wesdiscordbot> Currently, when attack is fired the unit's facing has already been changed 20190318 19:36:29<+wesdiscordbot> Okay, that's the issue 20190318 19:36:49<+wesdiscordbot> So my gut feeling was right, 1.14 changed existing behaviour in that regard, in 1.12 the unit's facing hasn't been set yet 20190318 19:38:22<+wesdiscordbot> So since as usual I've been bitten in the ass by unexplained behaviour changes I guess I'll just have to rewrite the map objective's logic entirely 20190318 19:39:01< gfgtdf> that mitgh have been the fix the the OOS facing in disable animations issue i mentioned earlier. 20190318 19:39:29<+wesdiscordbot> Good job but the way you fixed it makes things more difficult 20190318 19:40:11< gfgtdf> (i wasn't the one who fixed it celmin did, (which doenst mean i disagree with the fix) 20190318 19:40:43<+wesdiscordbot> Fortunately there's only one unit that can change the target's facing and be relevant to the map objective so I should just be able to keep track of attacks involving that unit 20190318 19:43:07< gfgtdf> doesn't* 20190318 19:57:45<+wesdiscordbot> So I need about 7 event handlers where before I only had 2 😅 20190318 20:05:38<+wesdiscordbot> (Add-on servers) Does 'Retired instance' mean that people can't upload stuff to that server anymore? 20190318 20:05:49<+wesdiscordbot> They can't upload or download from it 20190318 20:06:36<+wesdiscordbot> You mean, they can't download from it using Wesnoth, right? 20190318 20:06:55<+wesdiscordbot> (Only regarding the download part.) 20190318 20:07:00<+wesdiscordbot> Yes 20190318 20:07:06<+wesdiscordbot> Okay, thanks. 20190318 20:07:20<+wesdiscordbot> Any particular reason you wanted to know? 20190318 20:09:01<+wesdiscordbot> I'm keeping this huge list of add-ons up to date and it's nice to know that I won't have to check up more or less regularly on most of the old add-on servers once I've typed in the existing add-ons information. 20190318 20:10:27<+wesdiscordbot> This one. https://docs.google.com/spreadsheets/d/1C3RJNgIfYY6H6wU73drO8qSByelZNBXra-pvwNEu8RQ/htmlview#gid=1243457228 20190318 20:16:20<+wesdiscordbot> For anyone who might be curious what the resulting fix looks like and doesn't mind massive spoilers for my campaign: https://github.com/project-ethea/After_the_Storm/commit/176d9e1c0f4301d1e14eeabb5e14f5bc9126556b 20190318 20:28:35<+wesdiscordbot> https://github.com/wesnoth/wesnoth/issues/3983 This isn't really a bug, so I can close this, right? 20190318 20:31:32<+wesdiscordbot> sure 20190318 20:43:08<+wesdiscordbot> Why list the link to the 1.7 add-on server if said server is completly empty? 20190318 20:43:17<+wesdiscordbot> https://addons.wesnoth.org/1.7/ 20190318 20:45:34<+wesdiscordbot> It shouldn't be empty in the first place 20190318 20:46:15<+wesdiscordbot> Huh 20190318 20:46:37<+wesdiscordbot> For some reason the files for the 1.7.x instance do not exist, I'm pretty sure we had one? 20190318 20:48:11-!- irker584 [~irker@wesnoth/umc-dev/bot/shikadibot] has joined #wesnoth-dev 20190318 20:48:11< irker584> wesnoth: Iris Morelle wesmere:master e505aa0b89f3 / static/docroot/addons/index.xml: static: We appear to have lost the 1.7.x campaignd instance files https://github.com/wesnoth/wesmere/commit/e505aa0b89f308c8f7925351604b99c2e5d7a998 20190318 20:49:14-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20190318 20:50:54<+wesdiscordbot> How does one lose something like this? 😅 20190318 21:09:43<+wesdiscordbot> Any number of reasons 20190318 22:01:21<+wesdiscordbot> Is there any known way to make 'saving the random seed' fail? (E.g. updating the UMC between scenarios.) 20190318 22:02:43<+wesdiscordbot> Because I have a save for a UMC campaign where I know for sure that I checked the box for saving the random seed and reloading it doesn't yield the same results. 20190318 22:03:23<+wesdiscordbot> (And it was working in the previous scenario (excluding the dialog scenario inbetween).) 20190318 22:04:13<+wesdiscordbot> This scenario works. 20190318 22:04:13<+wesdiscordbot> https://cdn.discordapp.com/attachments/259976436490829825/557323398691422208/Cots-Flight-Auto-Save3.gz 20190318 22:04:27<+wesdiscordbot> This one doesn't. 20190318 22:04:27<+wesdiscordbot> https://cdn.discordapp.com/attachments/259976436490829825/557323455570247687/Cots-Betrayal-Auto-Save1.gz 20190318 22:04:50<+wesdiscordbot> I just load the save and end the turn. 20190318 22:09:22<+wesdiscordbot> In case the specific scenario is somehow to blame. 20190318 22:09:23<+wesdiscordbot> https://cdn.discordapp.com/attachments/259976436490829825/557324697013059595/05_Betrayl.cfg 20190318 22:36:25-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev 20190318 22:44:02< gfgtdf> i see nothgin suspicious in that scenario? 20190318 22:44:25< gfgtdf> what exactly is not workign as expected? Do you get differn traits when you recruit the same unit ? 20190318 22:46:46< gfgtdf> whats suspoicious that is that your 'Betrayal' save has 8301 random calls even though it was the frst turn 20190318 22:48:25< gfgtdf> wait i think there isa bug, mt_rng::seed_random does `random_calls_ += call_count;` when it shodul do `random_calls_ = call_count;` 20190318 22:49:17<+wesdiscordbot> The very first fight has already varying results. There is always an Assasin attacking the General. Sometimes he hits him not at all. Sometimes he hits him 1-4 times. 20190318 22:49:37<+wesdiscordbot> The number of hits the General scores on the Assassin varies as well. 20190318 22:49:47< gfgtdf> is it an ai side that starts the attack ? 20190318 22:49:52<+wesdiscordbot> Yes. 20190318 22:50:41< gfgtdf> the ai _decisions_ are generally not effects by the detemistic rng it has a seperate rng, this only effects ai decisiosn though not attackl results 20190318 22:51:08< gfgtdf> but if the ai decisions result in differnt attacking order it will of course also result in differtnt attack results 20190318 22:51:22<+wesdiscordbot> That is not the case here. 20190318 22:51:40<+wesdiscordbot> It is always the same Assassin attacking the General. 20190318 22:51:55<+wesdiscordbot> But the attack has varying results, which should not happen, right? 20190318 22:52:05< gfgtdf> maybe he soemtimes attaly before recruiting and soemtimes recuits before attacking ? 20190318 22:52:44< gfgtdf> or he recruits different units? (in the fog in in keep before attacking) 20190318 22:53:17<+wesdiscordbot> Hm. So recruiting can influences the attack results? (You are talking about Flight? Flight seems to work fine, I'm worried about Betrayal.) 20190318 22:53:40< gfgtdf> im takign about ther scenario that does not 'work' 20190318 22:53:53<+wesdiscordbot> That's Betrayal and there is no fog present. 20190318 22:54:11< gfgtdf> so does he recruit before attacking ? 20190318 22:54:50<+wesdiscordbot> Yes. 20190318 22:55:25<+wesdiscordbot> I'm still counting which recruits make which attack results happen. 20190318 22:55:35< gfgtdf> then that is likeley to be the casue, if he rectuit differnt units the later attack results will be differnt as traits/attack use the same rng. 20190318 22:55:55< gfgtdf> so if some units hav less traits than other of if he recuits less unit becasue they cost more. 20190318 22:56:42<+wesdiscordbot> All units have the same number of traits and he always recruits two units in the first turn. 20190318 22:56:44-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 272 seconds] 20190318 22:57:02<+wesdiscordbot> *all recruitable 20190318 22:58:25< gfgtdf> names also are used in the rng, maybe im also forgetting soemthing else 20190318 22:59:22<+wesdiscordbot> Also, the recruited units get different traits if I reload (but they might get always the same traits for the same recruit order). 20190318 23:01:09<+wesdiscordbot> They do get usually the same set of names though. But that isn't always the case as well. 20190318 23:04:27<+wesdiscordbot> Maybe some traits are more/less likely to be picked for some unit types and traits are using the same rng as attacks. Is that possible? 20190318 23:04:40< irker584> wesnoth: Lennard wesnoth:1.14 6216f82df590 / po/wesnoth-tutorial/de.po: style and spelling fixes, especially missing commas https://github.com/wesnoth/wesnoth/commit/6216f82df59011b804e0afab802bcab8391fd7ab 20190318 23:05:55<+wesdiscordbot> This is a confusing bug. 20190318 23:07:41<+wesdiscordbot> (Or if it's the names, some names are more likely for some (human) units than for other (human) units, right?) 20190318 23:16:09< gfgtdf> its probably gender, soem units have two genders resulting in one extra call 20190318 23:16:38< gfgtdf> while others have only one gender 20190318 23:16:40<+wesdiscordbot> Huh. 20190318 23:17:03< gfgtdf> so what results you ger proably depends on how many of the units are units with two genders 20190318 23:17:14< gfgtdf> get* 20190318 23:17:30<+wesdiscordbot> Let me check. That would mean up to 3 different results, right? 20190318 23:18:01< gfgtdf> if it always recruits two units then yes 20190318 23:18:18-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 250 seconds] 20190318 23:22:16<+wesdiscordbot> So far it seems to hold up. Names seem to use a different rng though. (Or the thing with some names more likely for some units than others.) 20190318 23:25:50<+wesdiscordbot> (I've reloaded like 20 times and it stays consistent if you filter it by the number of gender checks.) 20190318 23:26:34<+wesdiscordbot> Admittedly I only checked the first fight, but I'd expect so variation over 7 attacks if it doesn't check out. 20190318 23:27:44<+wesdiscordbot> So, thanks for figuring this out gfgtdf. Onto the next question, does this count as bug or something that should be fixed? 20190318 23:28:54<+wesdiscordbot> (I'd say yes, because why should the potential gender of recruitable units influence the attacks? It also goes counter the premise of 'reloading won't change the attack results'.) 20190318 23:35:15-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev 20190318 23:37:04-!- madmax28_ [~madmax28@xdsl-87-78-153-124.nc.de] has joined #wesnoth-dev 20190318 23:37:42-!- madmax28 [~madmax28@2001-4dd6-d445-0-ba27-ebff-febc-e0cb.ipv6dyn.netcologne.de] has quit [Ping timeout: 264 seconds] 20190318 23:49:55< gfgtdf> well you can create a report if ou want to gather more opinions on it, but from the engine perspective it works as expected. 20190318 23:51:26< gfgtdf> i also don't think 'number of gender choiceds effecting attack results' is really more unexpected than 'number of previously recruited unit effectign attack results' or the order of attacks effecting attack results. 20190318 23:54:33<+wesdiscordbot> Leaving the hit chances constant the order of attacks does not effect attack results, right? 20190318 23:55:16<+wesdiscordbot> Unlike gender choices and apparently the number of previously recruited units. 🤔 20190318 23:57:02<+wesdiscordbot> Does the number of previously recruited units affect the attack results btw? (Let the whole recruit list be one-gender units.) 20190318 23:59:06< gfgtdf> all of this changes the results, changing orer, number of recruits etc 20190318 23:59:17<+wesdiscordbot> "random number generators" aren't random at all. You know what the next number will, be, and the 2nd next.. so the count matters 20190318 23:59:43< gfgtdf> the results depend _on the number of times the rng was used before. --- Log closed Tue Mar 19 00:00:17 2019